principle-securitylisted

# Security Security bugs are design bugs. They are cheapest to fix before the first line of code is written. This skill teaches the principles that prevent security bugs at design time; the `security-auditor` subagent audits the resulting diff against vulnerability categories, secret patterns, and language foot-guns post-implementation. ## Trust Boundaries Name every boundary where data crosses trust levels. Validate at the boundary, not inside it. - Name the boundary explicitly: user-to-service, service-to-service, internal-to-DB, public-to-admin. - Validate at the boundary once — do not scatter input checks throughout internal code. - Allowlist what is known-good; denylist silently grows as attackers find gaps. - Structural validity (is it an integer?) is not semantic validity (is it *your* integer?). - Re-validate whenever data crosses a boundary again — even "internal" calls. ## Authentication is Not Authorization AuthN proves identity. AuthZ enforces policy. Confusing them produces exploitable gaps. - Authentication answers "who are you?"; authorization answers "can you do this to that?". - Enforce authorization on the resource, not the route — routes change; resources don't. - Default-deny: if no explicit grant exists, the answer is no. - Guard against confused deputy: a service acting on behalf of a user must not exceed that user's privileges. - Token revocation and session invalidation are Day-1 design concerns, not afterthoughts. ## Secrets Belong in Secret Sto