hunting-broken-object-level-authorizationlisted

# Hunting broken object-level authorization: follow the id to the access The most common serious API bug is also the simplest: a handler takes an object reference from the client, fetches or mutates that object, and never checks that the caller is allowed to touch *this* object. Authentication passes, the route filter passes, the query runs, and user A reads user B's record by changing one id. The bug is not in the routes that are protected; it is in every access that trusts a client-supplied reference without binding it to the caller. You find it by following the reference from the request to the data access and asking, at the access, what proves this is the caller's object. ## When to use - You are reviewing an API or handler that fetches or changes a record by an id, key, slug, filename, or reference the client supplies. - References travel in the path, query, body, a nested field, a batch item, or a token. - Access control depends on the object belonging to the caller, not just on the caller being logged in. ## Scope check Test object access only in systems you own or are authorized to test, with test accounts across at least two users and, where relevant, two tenants. If you can't name the authorization, stop. ## The loop 1. **Enumerate every client-supplied object reference.** Inventory each endpoint that accepts an object identifier and where it arrives: path segment, query parameter, body field, an id nested inside a JSON object or array, a batch of i