API Authorization & BOLA

Authentication answers who is calling. Authorization answers what that caller may do to this specific object. Broken object-level authorization (BOLA), often discussed alongside IDOR, is when the API accepts an identifier — in the path, the query, or the body — and returns or changes the record without checking that this caller owns it or is allowed to touch it.

Picture a notes API. Account A created note 100. Account B created note 200. Both are ordinary users. If A's session can read note 200, the API authenticated A and then skipped the ownership check. That is horizontal BOLA. If A can call an admin-only action such as listing every tenant's notes, that is a vertical authorization failure. Both matter. They are different findings because the fix and the impact differ.

The web curriculum already uses IDOR as one cell in a broader test matrix. This module is the dedicated treatment for APIs, where identifiers are the product. GraphQL nodes, REST resources, and batch endpoints all have the same question: did the server bind this object to this caller?

Frameworks often give you authentication middleware and leave authorization to each handler. A team copies a 'get by id' function, checks the session cookie, and ships. The happy path works. The missing line is the one that compares the object's owner to the session.

Clients sometimes send an owner field, a tenant id, or a role, and the server trusts it. Hidden form fields and JSON bodies are still caller-controlled. The trustworthy identity is the one the server derived from the session or the validated token, not a field sitting next to the data.

Unguessable identifiers (UUIDs, random strings) reduce casual browsing. They do not authorize the caller. If any other user, log, or feature reveals the identifier, the record is exposed whenever the check is missing. Security by obscurity is not the control you recommend.

Impact depends on the object. A profile name is not a medical record. Say what the object contains, who else could reach it, and what action succeeded: read, change, or delete. Business impact is confidentiality of that data, integrity if it was modified, and availability if it was removed.

A single authorized proof is enough when the rules of engagement say so. The finding is the missing check, demonstrated with accounts the client provided. It is not a tour through production data. If you can already see another customer's real content, stop, preserve the minimum evidence you agreed to keep, and notify the emergency contact.

Map the issue to OWASP API Security Top 10 API1 (Broken Object Level Authorization) and, when function-level gaps are separate, API5. Do not inflate a missing check into a different vulnerability class.

Written permission should name the API host, the environment (a non-production tenant whenever one exists), the test accounts, and whether reads are enough or changes are allowed. Production customer data is out of scope unless the contract says otherwise in writing. If the only environment is production, stop and ask for a lab tenant or an explicit decision from the owner.

You need two identities the client gave you, and objects those identities are supposed to own. Creating those objects yourself inside the test tenant is cleaner than borrowing real ones. Agree in advance what evidence looks like: a status code, whether the body differed, and a redacted screenshot. Agree what you will not keep.

Out of scope by default: other customers, other tenants, identifiers you found outside the test data, bulk enumeration, and any technique that changes or deletes data you were only allowed to read. A curious identifier is not an invitation.

Sign in as account A through the normal product flow. Note one object that belongs to A. Sign in as account B and note a different object that belongs to B. The question you are answering is whether A's session is refused when it asks for B's object, and whether B is refused for A's object.

Use the application's own interface first. A proxy such as Burp or ZAP is there so you can see whether the server, not the hidden button, made the decision. You are looking at the outcome: allowed, denied, or a body that contains the other account's data. You are not building a list of identifiers and you are not publishing a request to copy.

If the response for the other account's object contains that account's data, you have a candidate finding. Capture the minimum proof the rules allow, then stop. Do not continue across further records to 'see how bad it is.' Severity comes from the data class and who else could do the same, which you can explain without a tour.

Function-level gaps are the sibling test: can a normal test user open an admin-only action the client said should be denied? That is a separate note even when it sits on the same API. Do not fold it into BOLA just because both are authorization.

Recognition signs: any authenticated caller can name a record and receive it; the server accepts an owner or tenant field from the client; a denied user interface still succeeds when the call is repeated another way; creating an object as A and reading it as B works; admin fields appear for a standard test user. A 403 or an empty 404 on the other account's object is what you hope to see. A 200 with the other account's content is the failure.

Inconsistent status codes are a product decision, not automatically a vulnerability. Document what happened. The vulnerability is the missing check, not the choice between 403 and 404, unless that choice leaks the existence of objects the caller must not know about and the client cares about that leak.

The fix is server-side: every object access and mutation resolves the caller from the validated session or token, loads the object, and allows the action only if policy says so. Ignore client-supplied owner fields. Put the check in shared code. Add a regression test with two fixtures so the next endpoint cannot ship the hole again. Log the denial. Rate limits and random identifiers are useful, and they are not the fix.