Turn Security Requirements Into Invariants
Security requirements often begin as broad statements: “users must not read other users’ records,” “disabled accounts must not create new sessions,” or “a refund must require approval.” These statements describe the desired outcome, but they do not yet tell a developer where the rule must hold or what code should make it true. That gap matters. A rule enforced in one screen can be bypassed by another API path. A check performed before a state change can become stale before the write completes. A background worker may operate under different assumptions from the request that queued its job. The result is not necessarily a missing security feature; it is often a security property that was never made precise enough to enforce consistently.