add HTTP service hardening policy for 1.0 releases
All checks were successful
check / check (push) Successful in 5s
All checks were successful
check / check (push) Successful in 5s
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.
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Existing Repo Checklist
|
||||
last_modified: 2026-02-22
|
||||
last_modified: 2026-03-10
|
||||
---
|
||||
|
||||
Use this checklist when beginning work in a repo that may not yet conform to our
|
||||
@@ -78,6 +78,22 @@ with your task.
|
||||
`internal/`, `static/`, etc.)
|
||||
- [ ] Go migrations in `internal/db/migrations/` and embedded in binary
|
||||
|
||||
# HTTP Service Hardening (if targeting 1.0 and the repo is an HTTP/web service)
|
||||
|
||||
- [ ] Security headers set on all responses (HSTS, CSP, X-Frame-Options,
|
||||
X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
|
||||
- [ ] Request body size limits enforced on all endpoints
|
||||
- [ ] Read/write/idle timeouts configured on the HTTP server (slowloris defense)
|
||||
- [ ] Per-handler execution time limits in place
|
||||
- [ ] Password-based auth endpoints are rate-limited
|
||||
- [ ] CSRF tokens on all state-mutating HTML forms
|
||||
- [ ] Passwords hashed with bcrypt, scrypt, or argon2
|
||||
- [ ] Session cookies use HttpOnly, Secure, and SameSite attributes
|
||||
- [ ] True client IP correctly detected behind reverse proxy (trusted proxy
|
||||
allowlist configured)
|
||||
- [ ] CORS restricted to explicit origin allowlist for authenticated endpoints
|
||||
- [ ] Error responses do not leak stack traces, SQL queries, or internal paths
|
||||
|
||||
# Final
|
||||
|
||||
- [ ] `make check` passes
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: New Repo Checklist
|
||||
last_modified: 2026-02-22
|
||||
last_modified: 2026-03-10
|
||||
---
|
||||
|
||||
Use this checklist when creating a new repository from scratch. Follow the steps
|
||||
@@ -84,7 +84,22 @@ Template files can be fetched from:
|
||||
- [ ] No unnecessary files in repo root
|
||||
- [ ] All dates written as YYYY-MM-DD
|
||||
|
||||
# 5. Merge and Set Up
|
||||
# 5. HTTP Service Hardening (if the repo is an HTTP/web service targeting 1.0)
|
||||
|
||||
- [ ] Security headers middleware configured (HSTS, CSP, X-Frame-Options,
|
||||
X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
|
||||
- [ ] Request body size limits enforced on all endpoints
|
||||
- [ ] HTTP server read/write/idle timeouts configured (slowloris defense)
|
||||
- [ ] Per-handler execution time limits in place
|
||||
- [ ] Rate limiting on password-based authentication endpoints
|
||||
- [ ] CSRF tokens on all state-mutating HTML forms
|
||||
- [ ] Password hashing uses bcrypt, scrypt, or argon2
|
||||
- [ ] Session cookies set with HttpOnly, Secure, and SameSite attributes
|
||||
- [ ] True client IP detection configured with trusted proxy allowlist
|
||||
- [ ] CORS restricted to explicit origin allowlist for authenticated endpoints
|
||||
- [ ] Error responses never leak stack traces, SQL queries, or internal paths
|
||||
|
||||
# 6. Merge and Set Up
|
||||
|
||||
- [ ] Commit, merge to `main`
|
||||
- [ ] `make hooks` to install pre-commit hook
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Repository Policies
|
||||
last_modified: 2026-03-09
|
||||
last_modified: 2026-03-10
|
||||
---
|
||||
|
||||
This document covers repository structure, tooling, and workflow standards. Code
|
||||
@@ -128,6 +128,65 @@ style conventions are in separate documents:
|
||||
- Dockerized web services listen on port 8080 by default, overridable with
|
||||
`PORT`.
|
||||
|
||||
- **HTTP/web services must be hardened for production internet exposure before
|
||||
tagging 1.0.** This means full compliance with security best practices
|
||||
including, without limitation, all of the following:
|
||||
- **Security headers** on every response:
|
||||
- `Strict-Transport-Security` (HSTS) with `max-age` of at least one year
|
||||
and `includeSubDomains`.
|
||||
- `Content-Security-Policy` (CSP) with a restrictive default policy
|
||||
(`default-src 'self'` as a baseline, tightened per-resource as
|
||||
needed). Never use `unsafe-inline` or `unsafe-eval` unless
|
||||
unavoidable, and document the reason.
|
||||
- `X-Frame-Options: DENY` (or `SAMEORIGIN` if framing is required).
|
||||
Prefer the `frame-ancestors` CSP directive as the primary control.
|
||||
- `X-Content-Type-Options: nosniff`.
|
||||
- `Referrer-Policy: strict-origin-when-cross-origin` (or stricter).
|
||||
- `Permissions-Policy` restricting access to browser features the
|
||||
application does not use (camera, microphone, geolocation, etc.).
|
||||
- **Request and response limits:**
|
||||
- Maximum request body size enforced on all endpoints (e.g. Go
|
||||
`http.MaxBytesReader`). Choose a sane default per-route; never accept
|
||||
unbounded input.
|
||||
- Maximum response body size where applicable (e.g. paginated APIs).
|
||||
- `ReadTimeout` and `ReadHeaderTimeout` on the `http.Server` to defend
|
||||
against slowloris attacks.
|
||||
- `WriteTimeout` on the `http.Server`.
|
||||
- `IdleTimeout` on the `http.Server`.
|
||||
- Per-handler execution time limits via `context.WithTimeout` or
|
||||
chi/stdlib `middleware.Timeout`.
|
||||
- **Authentication and session security:**
|
||||
- Rate limiting on password-based authentication endpoints. API keys are
|
||||
high-entropy and not susceptible to brute force, so they are exempt.
|
||||
- CSRF tokens on all state-mutating HTML forms. API endpoints
|
||||
authenticated via `Authorization` header (Bearer token, API key) are
|
||||
exempt because the browser does not attach these automatically.
|
||||
- Passwords stored using bcrypt, scrypt, or argon2 — never plain-text,
|
||||
MD5, or SHA.
|
||||
- Session cookies set with `HttpOnly`, `Secure`, and `SameSite=Lax` (or
|
||||
`Strict`) attributes.
|
||||
- **Reverse proxy awareness:**
|
||||
- True client IP detection when behind a reverse proxy
|
||||
(`X-Forwarded-For`, `X-Real-IP`). The application must accept
|
||||
forwarded headers only from a configured set of trusted proxy
|
||||
addresses — never trust `X-Forwarded-For` unconditionally.
|
||||
- **CORS:**
|
||||
- Authenticated endpoints must restrict `Access-Control-Allow-Origin` to
|
||||
an explicit allowlist of known origins. Wildcard (`*`) is acceptable
|
||||
only for public, unauthenticated read-only APIs.
|
||||
- **Error handling:**
|
||||
- Internal errors must never leak stack traces, SQL queries, file paths,
|
||||
or other implementation details to the client. Return generic error
|
||||
messages in production; detailed errors only when `DEBUG` is enabled.
|
||||
- **TLS:**
|
||||
- The service itself may terminate TLS or sit behind a TLS-terminating
|
||||
reverse proxy, but HSTS headers and secure cookie flags must be set
|
||||
regardless so that the browser enforces HTTPS.
|
||||
|
||||
This list is non-exhaustive. Apply defense-in-depth: if a standard security
|
||||
hardening measure exists for HTTP services and is not listed here, it is
|
||||
still expected. When in doubt, harden.
|
||||
|
||||
- `README.md` is the primary documentation. Required sections:
|
||||
- **Description**: First line must include the project name, purpose,
|
||||
category (web server, SPA, CLI tool, etc.), license, and author. Example:
|
||||
|
||||
Reference in New Issue
Block a user