Security

Security in this method is not a checklist you skim at the end. It is a hostile, standing audit — CLAUDE_SECURITY.md — run by an auditor who assumes the code is wrong and every input is an attack until proven otherwise, who goes beyond the checklist, and who does not soften findings to be polite (Law 19). It is a pointer file, loaded when working on auth, data, or security, not at session start.

The mandate is specific. Every finding is delivered in a fixed shape — issue, severity, an approximate CVSS 3.1 score, the exact location (repo, file, function, layer), the precise attacker steps with no handwaving, the impact, and a code- or config-level fix with no vague advice. Be careful with input is not a finding; this handler decodes untrusted JSON without a schema, letting an attacker do X is.

The audit walks thirteen layers, from the outside in. Frontend foundations: no secrets in the client bundle, the API access token fetched server-side and never handed to client JS, a nonce-based CSP that blocks inline scripts, source maps off in production. Backend API: every route validates its own auth — no trust inherited from a gateway (Law 1) — every parameter validated for type, length, format, and range, unknown fields rejected, no user input built into shell, SQL, or template strings. Database and storage: row-level security enabled on every table (the audit literally checks that pg_tables where rowsecurity=false returns empty), policies scoped by the verified subject and never a user-supplied column, service credentials only in the backend env. Authentication: identity fully delegated — no custom JWT signing, no custom password hashing — the backend validating signature, issuer, audience, and expiry on every request, with admin tokens from a separate tenant (Law 21).

The remaining layers carry the same posture into deploy, CI/CD, RLS depth, rate limiting, caching, resilience, logging, and recovery. Two themes recur. Defense in depth: anything that matters gets two independent controls, so an in-app rate limit backs the edge because a header-spoofing attacker walks around Cloudflare alone (Law 6). And don't leak existence: identical response and timing on auth flows, so an attacker cannot enumerate accounts (Law 7). Recovery is audited as seriously as access — backups with tested restores (an untested backup is not a backup), a rehearsed bootstrap-from-zero, secret rotation under thirty minutes (Law 23).

What makes it a control rather than a document is cadence. The full audit runs before every major ship, after any dependency update, after any auth-flow change, after any new route or table — and unattended on a schedule (default fourteen days; settable to five-day, monthly, or six-monthly) through a scheduled pipeline, zero human trigger required (Law 20). A manual re-audit has a trigger phrase that names the isolated passes explicitly: separate passes for auth, payments, RLS, service keys, and env vars; flag every issue; skip nothing to be polite. Every high-priority class it digs into — broken auth, IDOR, exposed secrets, injection, XSS, CSRF, SSRF, insecure uploads, unsafe AI endpoints — maps to an entry in ANTIPATTERNS.md, the subject of the next chapter, and the two are kept in sync.