hunting-broken-object-level-authorization

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 ids, a value carried in a token or cookie, or a filename. Each reference that selects an object is a source. Do not stop at the obvious path id; references hide in nested and batch payloads.

2. Follow each reference to the data access. Trace the reference from where it enters to where it selects the object: the query filter, the key lookup, the file open, the mutation. That access is the sink. The question the whole audit turns on is asked here, so find the exact access each reference reaches.