Broken object level authorisation (BOLA)
In API security, broken object level authorisation (BOLA) is the failure to verify that the caller is entitled to the specific object their request names. It is the first entry in the OWASP API Security Top 10 and, in an API test, the flaw that most often exposes another tenant’s records.
How it works
An API endpoint receives an object identifier as a path segment, a query parameter, a body field or a header, resolves it, and returns or modifies the object. Object level authorisation is the check that sits between resolving and acting: does the identity behind this token have a relationship with this object that permits this operation. When that check is missing, partial, or performed against data the client supplied, the endpoint is broken.
BOLA and IDOR describe the same underlying defect. IDOR is the older name and is used in web application reports; BOLA is the name used for APIs and the one an API report should use, because it separates the object level check from the function level check, which is a different failure with a different fix.
What goes wrong
APIs make this worse than classic web applications for a structural reason: the object graph is exposed directly, one identifier at a time, with no server-rendered page in between to hide it. Every resource, sub-resource and relationship is its own endpoint, so a single missing check on a nested route defeats a correct check on the parent.
The failure we see most is scoping by token claim without re-reading the object. The handler trusts a tenant identifier taken from the request instead of deriving it from the session, so the client simply supplies a different one. A close second is inconsistent enforcement across verbs and across representations: GET is guarded, PATCH is not; the JSON route is guarded, the bulk export is not; the versioned route is guarded and the previous version is still deployed and is not. Tenant isolation that holds in the user interface and fails in the API is the normal shape of the finding.
Where this shows up in an audit
We enumerate the endpoints from the specification, then test each one with a second account’s identifiers, and we test every verb the endpoint accepts rather than the one the documentation shows. The report states the endpoint, the verb, the identifier substituted, and the exact fields returned that belonged to another tenant. We also record whether the operation was logged, because an unlogged cross-tenant read is a much harder incident to reconstruct. This is part of how we work through an API object by object.