Security

Admin → Security opens on the Security Center. Header grade, Headers, Advanced, Admin URL, Audit log, File integrity, and Web server are the other pages. Header APIs: GET/PUT /api/security/headers, reset, and POST /api/security/audit (grades a draft). Config is cached briefly (security-headers:config).

Security Center#

The Security Center lists the checks this installation can answer, each as Pass, Warning, Fail, Not verified, or Not applicable, and says whether it is a configuration or a deployment check. A passing row is that one check, not a grade for the site.

• Runtime: the Node.js version, whether a core update is available, debug mode, and whether the install wizard is still open.
• Accounts: administrators without an authenticator, device sessions, and API keys without an expiry date.
• Transport: the session cookie policy, the public URL, trusted proxies, and the response-header policy (the result stays on Header grade).
• Files: file integrity and the web-server setup for uploads.

Backups are always shown as not verified, because Justflows cannot see them. An update check that has not finished is not reported as up to date. On a multisite installation, a hosted site's Security Center shows only its own checks; installation-wide checks such as the Node.js version, core updates, the install wizard, the session cookie, the public URL, trusted proxies, file integrity, and the web-server setup stay on the main site.

File integrity#

Security → File integrity compares each installed plugin and theme with the baseline recorded when it was installed from a trusted package. A changed, removed, or added file is reported, and that extension is not loaded. Reinstall it from a trusted package to restore it. An extension installed before baselines existed stays Not verified and still runs.

Core files are compared with the signed file manifest in the release archive. Uploads, storage, themes, plugins, and installed extensions are left out of that manifest. A development checkout without the manifest stays Not verified.

Web server#

Justflows checks every request for an upload in the application: the host, the site, and whether the file is private. A web server that serves /uploads/ straight from disk, or a CDN that caches private files as public, skips that check. Security → Web server on the main site shows the file to copy for Apache, LiteSpeed, nginx, an Apache reverse proxy, Passenger, and Docker, filled in with this installation's port and uploads folder. Justflows refreshes the site-root .htaccess itself while its first line is intact; it never rewrites nginx, a reverse proxy, Passenger, or Docker configuration.

Managed headers#

Thirteen headers, each scoped to all / public / admin: CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COEP, COOP, CORP, X-Permitted-Cross-Domain-Policies, X-DNS-Prefetch-Control, Origin-Agent-Cluster, X-XSS-Protection. Advanced adds custom headers, removing Server, and JSON export. Plugins can still adjust via http.responseHeaders.

Request hardening#

• CSRF — double-submit cookie jf_csrf + header x-csrf-token on mutating /api/* except login and install. Tokens rotate with token_version.
• Sessions — jf_session, HMAC-SHA256, 14 days. Password change, reset, 2FA changes, and logout bump token_version and reject old cookies.
• Passwords — PBKDF2-SHA256, 310k iterations, minimum 12 characters.
• 2FA — optional TOTP with encrypted recovery codes. See Users and roles.
• Login rate limit — 20/IP and 10/email per 15 minutes; exhausted windows lengthen up to 8× and send Retry-After.
• Express — default x-powered-by off; Justflows sets X-Powered-By: Justflows.
• Password reset — optional self-service reset by email: single-use SHA-256-hashed tokens, identical responses whether or not the address exists, and per-address and per-IP rate limits. See Users and roles.
• Correlation IDs — every HTTP response carries one, and sanitized errors are retained in a bounded buffer for Diagnostics.

Multisite and outbound hardening

• User management stays within your own access. Someone who manages users can assign roles, permissions, and scopes only within what they hold, and cannot change or remove an administrator. Changing, rotating, revoking, or deleting an API key requires that key's access, including its scope, to sit within the caller's own.
• Unpublished content stays editorial. A read-only role receives published content only. Drafts, archived items, scheduled items, and working revisions are visible to people who can edit that content or who wrote it. Deleting media needs the media delete capability, and site-wide preview needs permission to edit content on that site.
• Sign-in and recovery fail closed. An authenticator record that cannot be read is not treated as turned off. Each authenticator code and recovery code works once, even when two requests overlap. A password reset changes the password and revokes sessions together, or neither. In production the installation token is required even from a loopback address.
• Private files stay private. Private storage, update backups, rollback data, and trashed uploads are never served. Uploads have no public filesystem alias, and public upload reads are limited to 600 a minute per address.
• Outbound requests check the address they connect to. Webhooks, AI providers, and downloads refuse private addresses in every IPv6 form at connection time, and webhook responses are read only up to a small limit.
• Uploads are bounded. Each site has a limit on uploads in progress, oversized uploads are refused before and while they are read, and image processing runs a few at a time.
• Sites stay separate. A site that cannot be looked up gets a temporary error instead of another site's content, plugin routes answer only on sites where the plugin is on, and a sign-in only counts on the site it was made for.
• Packages must be pinned or Marketplace-signed. A signature carried inside a package's own manifest is not trusted.

Admin Content Security Policy#

The public site already enforces CSP by default. The admin now has its own enforcing policy as well, graded from the Security screen, because an admin session can install extensions and replace the core. Pre-session pages served by root server.js (/login, /install) also send security headers.

Admin URL#

Admin → Security → Admin URL moves the administration entry path off /admin. Reserved paths are rejected, a reachability check with automatic rollback runs before the change sticks, and the old path's behaviour (404 or redirect) is configurable. Staff sign in, request a reset, and reset their password only at <admin path>/login, /forgot-password, and /reset-password, and once the path is moved, /admin/* answers 404. A staff account on the member sign-in page gets exactly the answer a wrong password gets, before any two-factor prompt, so the member pages never confirm a staff account or reveal the admin path. Each site keeps its own admin path. The redirect from a renamed admin address back to the login page is not cached. JF_ADMIN_PATH_RECOVERY is the environment override for proxy or cache recovery, and its instructions show only on the platform site.

Audit log#

Admin → Security → Audit log reads the audit_log table (migrations 0008 / 0009). It records sign-ins and failed sign-ins, password changes and resets, 2FA enrolment, account creation, role changes and deletions, plugin/theme/CSS-provider installs and activations, core updates, security-header changes, and public-API toggles. Later releases also record custom-role and per-user access-policy changes, trash / restore / purge, password-reset requests and completions, admin-URL changes, and automatic-update runs. Every change an AI agent or the admin assistant makes is recorded as ai.tool_called (never the arguments), and saving or removing an AI provider key as ai.provider_saved / ai.provider_removed. Writes never throw into the action they describe. Retention defaults to 365 days (JF_AUDIT_RETENTION_DAYS).

Packages and updates#

Package authenticity is required by default. A .jfpkg needs a valid Marketplace signature or a digest in JUSTFLOWS_TRUSTED_PACKAGE_DIGESTS; JUSTFLOWS_ALLOW_UNSIGNED_PACKAGES=1 is the explicit legacy escape hatch. Core update digest pinning and HMAC signing are also available — see Configuration. Package and core archives are checked before anything is written: a plugin package is unpacked and parsed in a separate worker that can be stopped, a malformed archive is rejected, and absolute paths, links, special files, duplicate names, and incomplete listings are refused. A core update checks the signature before it extracts.