Add HTTP service hardening policy for 1.0 releases #17
Reference in New Issue
Block a user
Delete Branch "feature/http-service-hardening-policy"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #16
Adds a comprehensive HTTP/web service security hardening policy to
REPO_POLICIES.mdthat must be satisfied before tagging 1.0. The policy covers all items sneak specified (without limitation):Security headers — HSTS (min 1 year, includeSubDomains), CSP (restrictive
default-src 'self'baseline), X-Frame-Options / frame-ancestors, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy.Request/response limits — max request body size on all endpoints, max response size for paginated APIs, ReadTimeout + ReadHeaderTimeout (slowloris defense), WriteTimeout, IdleTimeout, per-handler execution time limits.
Authentication & session security — rate limiting on password-based auth (API keys exempt as high-entropy), CSRF tokens on state-mutating forms (header-auth APIs exempt), bcrypt/scrypt/argon2 for passwords, session cookies with HttpOnly + Secure + SameSite.
Reverse proxy awareness — true client IP detection via X-Forwarded-For/X-Real-IP with trusted proxy allowlist (never trust unconditionally).
CORS — explicit origin allowlist for authenticated endpoints; wildcard only for public unauthenticated read-only APIs.
Error handling — no leaking stack traces, SQL queries, file paths, or implementation details to clients.
TLS — HSTS and secure cookie flags required regardless of whether the service terminates TLS directly or sits behind a reverse proxy.
The policy is explicitly non-exhaustive (defense-in-depth: "when in doubt, harden").
Also adds corresponding checklist sections to
EXISTING_REPO_CHECKLIST.mdandNEW_REPO_CHECKLIST.mdso that HTTP hardening is verified during repo setup and 1.0 preparation.@clawbot having all of these as checklist items in a new repo is nonsensical.
Understood — the HTTP hardening checklist items don't belong in
NEW_REPO_CHECKLIST.mdsince new repos won't have HTTP services yet. Dispatching rework to remove those changes and keep the new-repo checklist clean.oh, we never terminate TLS in our services by policy. they're designed to always go behind a reverse proxy that terminates TLS out of process.
Rework complete. Removed the HTTP service hardening checklist section from
NEW_REPO_CHECKLIST.md— these items don't belong in a new-repo setup checklist since the repo won't have an HTTP service (or be targeting 1.0) at creation time.The HTTP hardening policy remains in:
REPO_POLICIES.md— the authoritative policy textEXISTING_REPO_CHECKLIST.md— for 1.0 prep on repos that already have an HTTP serviceChanges:
NEW_REPO_CHECKLIST.mdto its pre-PR state (removed section 5 "HTTP Service Hardening", restored original section numbering)docker build .passes (make checkall green)Good catch — the policy should reflect that our services never terminate TLS directly; they always sit behind a reverse proxy. Dispatching another rework to update the policy text accordingly (remove any language implying direct TLS termination, clarify reverse-proxy-only architecture).
Rework complete. Addressed the TLS policy feedback:
Change: Updated the TLS subsection to state that services never terminate TLS directly — they are always deployed behind a TLS-terminating reverse proxy and listen on plain HTTP. Previously the text said "The service itself may terminate TLS or sit behind a TLS-terminating reverse proxy," which presented it as one of two options.
HSTS headers and
Securecookie flags are still required so the browser enforces HTTPS end-to-end, even though the app itself serves plain HTTP.docker build .passes (make checkall green)