Security review ¶

This is the implementation’s own review, not an independent audit.

• Toolchain: initial scanning identified reachable standard-library issues in Go 1.26.2. The minimum version was raised to 1.26.10 and scanning rerun; no reachable vulnerabilities remained.
• Filesystem writes: upload temporary files were changed to creation through os.Root, retaining the rooted-directory boundary throughout creation and rename. Path traversal and failed oversized replacements are tested.
• Model administration: editable fields must be explicitly listed. Primary keys and associations cannot be mass-assigned. Required authorization/scope callbacks and post-edit permission checks prevent an implicit allow-all policy; role-denial cases are integration-tested.
• Session transitions: login rotates tokens and clears prior session state; logout destroys the session. Old tokens and pre-login CSRF tokens are rejected in tests.
• CSRF: all unsafe cookie-authenticated methods, including JSON, require the session token. Token comparison is constant-time; token pages are not cacheable.
• Data output: ordinary template strings are escaped; the article API projects only ID/title. Authentication hashes are excluded. Template errors are buffered before headers are written.
• Database: values are parameterized; application request contexts reach GORM. Explicit SQL migration tests cover contention, rollback, version history, constraints, and cancellation. Raw SQL identifiers remain developer-controlled.
• HTTP: explicit allowed hosts, body limits, timeouts, local-only redirects, and generic error responses provide a baseline. No forwarded-header trust is inferred.
• Jobs: rollback/commit behavior is tested. Worker idempotency and external side-effect retry policy remain application responsibilities.

Before public deployment, apply login/expensive-endpoint rate limits at the gateway or application, use the accounts browser bridge or integrate revocation with a custom user store, apply explicit object permissions, use HTTPS and verified database TLS, validate the object-storage signer, and review the complete application. These are deployment boundaries, not capabilities proved by this repository. External review and beta adoption remain release gates in PLAN.md.

• Browser account integration: cookie sessions retain account tokens server-side, resolve disablement/revocation on each request, and enforce bounded CSRF-protected forms. Recovery responses are uniform and single-use tokens are covered by PostgreSQL tests.
• Email: required verified TLS by default, no credentials over plaintext, MIME/header validation and envelope-only Bcc are tested against local SMTP fixtures.
• Logging: structured credential fields/groups are redacted before handlers; default requests omit private URL/body/header data, and panic values/query arguments are excluded. Free-form text and application-provided custom objects remain the caller’s responsibility.