An endpoint returns an invoice given its identifier, and any logged-in user who supplies another customer's identifier receives their invoice. Explain why this class of defect is so common, state the enforcement rule that prevents it, and say why switching to random unguessable identifiers is not the fix.

## Why it is the most common serious defect The function-level rule ('only a billing role may call this') is uniform, declarative and enforceable in one place, so it gets written. The object-level rule ('this invoice must belong to the caller's account') differs per resource and needs domain knowledge, so it lives inside handlers. Missing code raises no error, no type check and no test failure unless someone wrote a test for the negative case. Meanwhile all the traffic is authenticated, so logs and anomaly detection see nothing unusual. The bug is invisible from every direction except a deliberate test. ## The enforcement rule Every request re-derives the authorization decision from state the server owns, for every object it touches. Client input designates - which record, which page, which field - and never asserts entitlement. A request may say 'invoice 981'; it may not effectively say 'as tenant 7' or 'with role admin'. The same rule catches the mutation variant, where a create or update carries an owner, tenant or price field that the handler binds straight onto the entity. And the check must cover every object touched, not just the top-level one: nested identifiers, bulk operations, export jobs and search results are each an access decision. ## Ranking the defences Use the same ladder as elsewhere in secure design, weakening from guarantee to heuristic as you descend. There is no escaping or transformation rung here because no parser is involved; the rungs are: 1. **Structural separation.** Make the violation unrepresentable. Data access goes through a layer that cannot be called without the principal's scope, so every query is filtered by tenant or owner by construction. A developer who forgets is unable to express the unscoped query. Enforcement in the data store itself is the same idea pushed one level down. 2. **Enumerated, code-owned permission checks.** A single authorization component every handler must consult, with resource types and actions drawn from a closed set the code owns. A real guarantee about which decisions exist, though it still relies on the call being made. 3. **Per-handler checks.** Correct when present. The failure mode is silent omission, and coverage decays as the codebase grows. 4. **Detection.** Audit logs, alerting on cross-tenant access patterns, negative tests in the pipeline. Valuable, but it tells you afterwards. Unguessable identifiers do not appear on this ladder at all, because they change the probability of an attacker finding a target rather than the outcome when they do. They are worth having for other reasons - sequential identifiers leak business volume and make enumeration cheap - but as an access control they are obscurity: identifiers appear in shared URLs, browser history, referrer data, exports, log aggregation, support screenshots and adjacent endpoints' responses, and once one escapes, access is permanent because nothing checks. ## Deny by default, and the existence question New endpoints must be denied unless a rule permits them, so forgetting to classify a route fails closed rather than open. When a check fails, decide deliberately what the response reveals: distinguishing 'exists but forbidden' from 'does not exist' hands an attacker an existence oracle over identifiers, which matters wherever mere existence is sensitive. Returning the same not-found answer for both is often right; the important part is that it is a decision, not an accident. ## Testing it The only reliable coverage is negative and systematic: for each resource, a test where principal A requests principal B's object and expects a denial. Because the defect is an absence, a per-resource test matrix is what turns 'we remembered' into 'the pipeline checks'.