Add HTTP service hardening policy for 1.0 releases #17

2026-03-11T01:48:20+01:00

clawbot прокомментировал(а)

2026-03-11 01:48:20 +01:00

Соавтор

Closes #16

Adds a comprehensive HTTP/web service security hardening policy to REPO_POLICIES.md that 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.md and NEW_REPO_CHECKLIST.md so that HTTP hardening is verified during repo setup and 1.0 preparation.

Closes #16 Adds a comprehensive HTTP/web service security hardening policy to `REPO_POLICIES.md` that 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.md` and `NEW_REPO_CHECKLIST.md` so that HTTP hardening is verified during repo setup and 1.0 preparation.

clawbot добавил(а) 1 коммит 2026-03-11 01:48:20 +01:00

add HTTP service hardening policy for 1.0 releases

check / check (push) Successful in 5s

Информация

2946dd2f14

Add comprehensive security hardening requirements to REPO_POLICIES.md
that HTTP/web services must satisfy before tagging 1.0. Covers security
headers (HSTS, CSP, XFO, X-Content-Type-Options, Referrer-Policy,
Permissions-Policy), request/response limits, slowloris timeouts, rate
limiting on password auth, CSRF, session cookie security, reverse proxy
IP detection, CORS restrictions, and error handling.

Also add corresponding checklist sections to EXISTING_REPO_CHECKLIST.md
and NEW_REPO_CHECKLIST.md for verification during repo setup.

sneak прокомментировал(а)

2026-03-11 02:03:11 +01:00

Владелец

@clawbot having all of these as checklist items in a new repo is nonsensical.

@clawbot having all of these as checklist items in a *new repo* is nonsensical.

clawbot добавил(а) метку needs-rework

2026-03-11 02:03:31 +01:00

clawbot прокомментировал(а)

2026-03-11 02:03:31 +01:00

Автор

Соавтор

Understood — the HTTP hardening checklist items don't belong in NEW_REPO_CHECKLIST.md since new repos won't have HTTP services yet. Dispatching rework to remove those changes and keep the new-repo checklist clean.

Understood — the HTTP hardening checklist items don't belong in `NEW_REPO_CHECKLIST.md` since new repos won't have HTTP services yet. Dispatching rework to remove those changes and keep the new-repo checklist clean.

sneak прокомментировал(а)

2026-03-11 02:05:06 +01:00

Владелец

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.

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.

clawbot добавил(а) 1 коммит 2026-03-11 02:05:14 +01:00

remove HTTP hardening checklist from NEW_REPO_CHECKLIST.md

check / check (push) Successful in 5s

Информация

32cfb84831

New repos aren't HTTP services at creation time — these items only
make sense in EXISTING_REPO_CHECKLIST.md (for 1.0 prep) and in the
policy itself (REPO_POLICIES.md).

clawbot прокомментировал(а)

2026-03-11 02:05:27 +01:00

Автор

Соавтор

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 text
EXISTING_REPO_CHECKLIST.md — for 1.0 prep on repos that already have an HTTP service

Changes:

Reverted NEW_REPO_CHECKLIST.md to its pre-PR state (removed section 5 "HTTP Service Hardening", restored original section numbering)
docker build . passes (make check all green)

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 text - `EXISTING_REPO_CHECKLIST.md` — for 1.0 prep on repos that already have an HTTP service Changes: - Reverted `NEW_REPO_CHECKLIST.md` to its pre-PR state (removed section 5 "HTTP Service Hardening", restored original section numbering) - `docker build .` passes (`make check` all green)

clawbot прокомментировал(а)

2026-03-11 02:05:53 +01:00

Автор

Соавтор

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).

clawbot добавил(а) 1 коммит 2026-03-11 02:07:37 +01:00

fix: clarify TLS policy — services never terminate TLS directly

check / check (push) Successful in 5s

Информация

6be01ea81f

Our services always sit behind a TLS-terminating reverse proxy and
listen on plain HTTP. Updated the TLS subsection to state this as
policy rather than presenting it as one of two options.

clawbot прокомментировал(а)

2026-03-11 02:07:51 +01:00

Автор

Соавтор

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 Secure cookie flags are still required so the browser enforces HTTPS end-to-end, even though the app itself serves plain HTTP.

docker build . passes (make check all green)
No other files changed
README untouched

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 `Secure` cookie flags are still required so the browser enforces HTTPS end-to-end, even though the app itself serves plain HTTP. - `docker build .` passes (`make check` all green) - No other files changed - README untouched

sneak слил(а) коммит 41005ecbe5 в main

2026-03-11 02:11:33 +01:00

sneak удалил(а) ветку feature/http-service-hardening-policy

2026-03-11 02:11:33 +01:00

sneak упомянул эту задачу в коммите

2026-03-11 02:11:34 +01:00

Add HTTP service hardening policy for 1.0 releases (#17)

clawbot сослался(ась) на этот запрос на слияние

2026-08-09 07:39:50 +02:00

script/cibuild reports a green it did not earn: Docker serves the `make check` layer from cache #26

clawbot сослался(ась) на этот запрос на слияние

2026-09-25 12:25:17 +02:00