defense-in-depthlisted

# Defense in Depth When an invariant matters — security, data integrity, money, identity — one layer of protection is not enough. The point is not paranoia. The point is that any single layer can be wrong, bypassed, or skipped, and the next layer catches it. ## Iron Law **For invariants that must hold, enforce them at every layer that touches the data.** Front-end validates, API validates, DB constrains, audit logs catch. ## Red Flags - "I already check this in the UI." - "The API caller would never send that." - "We trust the upstream service to validate." - "The DB schema allows it but the app won't write it." - One single check at one single layer, with the system relying on it. Each of those is one bug, one bypassed front-end, one rogue script, one curl command away from disaster. ## Where the layers live For a typical request flow, the layers are roughly: 1. **Client / UI** — guides the user, catches typos, gives fast feedback. 2. **Network boundary** — gateway / WAF, authentication, rate limit. 3. **Application layer** — business rules, authorization, validation. 4. **Persistence layer** — schema constraints, foreign keys, triggers. 5. **Audit / monitor layer** — logs, anomaly detection, replay-able trail. The same invariant should be expressible at multiple layers, with different jobs: - UI = **usability** (don't waste user's time) - API = **correctness** (don't trust the caller) - DB = **integrity** (don't trust the app) - Audit = **detection** (catch when t