and come up constantly in API security, often used interchangeably and occasionally treated as rivals. They are neither — they describe the same underlying failure from two different vantage points. This guide gives the precise distinction, shows why the difference rarely matters for testing, and lays out how to find both with cross-role replay.
The short answer#
- (Insecure Direct Object Reference) is the classic web-app term: the application exposes a reference to an internal object (an ID in a URL, parameter, or body) that a user can tamper with to access objects that are not theirs.
- (Broken Object Level Authorization) is the OWASP API Security term for the root cause: the server fails to verify the caller is authorized for the specific object referenced.
describes the symptom (a tamperable reference); names the missing check (object-level authorization). When you change GET /invoices/9182 to 9183 and see someone else’s invoice, that is an exploiting a flaw. Same bug, two lenses.
Why the terminology split happened#
The web-app community coined decades ago, and it lives in the OWASP testing guidance and broad access-control discussion (CWE-639). When OWASP built the API Security Top 10, it needed a name focused on the authorization decision rather than the reference, and became API1:2023 — the number-one API risk. So the split is largely historical and contextual: in web-app circles, in API circles.
Where they genuinely differ in emphasis#
The nuance worth keeping:
- emphasises the reference — predictable IDs, guessable filenames, sequential identifiers. Mitigations sometimes lean on unguessable references (UUIDs), which reduces discoverability but does not fix the missing authorization check.
- emphasises the check — it insists the fix is server-side object-level authorization, regardless of how guessable the reference is. A UUID you obtain through another channel is still exploitable if the check is missing.
That distinction matters for remediation: making IDs unguessable is defence in depth, not a fix. The fix is the authorization check.
How to test for both#
The detection technique is identical, because both are relational failures invisible to a single-session scanner:
- Establish multiple roles — at minimum a privileged role, a same-tenant lower-privileged role, and a cross-tenant stranger.
- Capture reference responses for object-referencing endpoints under the privileged role.
- Replay under other roles and diff — if a role receives an object it should not, you have found the bug, whether you call it or .
This is exactly what the Authorization Matrix walkthrough demonstrates end to end, and what API Pentesting runs across every role your app defines. The finding ships as deterministic proof: the request, both responses, and the leaked fields.
How to fix it#
The durable fix is the same for both:
# Pseudocode — enforce object-level authorization on every object access
def get_invoice(caller, invoice_id):
invoice = db.find(invoice_id)
if invoice.tenant_id != caller.tenant_id: # the check that prevents BOLA/IDOR
raise Forbidden()
return invoice
Add the ownership check at the service boundary on every object access. Unguessable identifiers are a useful extra layer, but they are not a substitute for the check.
Key takeaways#
- is the tamperable-reference symptom; is the missing-object-authorization root cause — same bug, two lenses.
- The terms split along web-app () vs API () community lines and are otherwise interchangeable.
- Unguessable IDs reduce discoverability but do not fix the underlying authorization gap.
- Test both with cross-role replay; fix both with a server-side object-ownership check.
FAQ#
Are and the same thing? Effectively yes — they describe the same broken-access-control failure. emphasises the tamperable object reference; emphasises the missing server-side authorization check. The OWASP API Top 10 uses .
Does using UUIDs instead of sequential IDs fix ? No. Unguessable identifiers make objects harder to discover but do not add the authorization check. If an attacker obtains a valid UUID, a missing check still leaks the object. The fix is server-side object-level authorization.
How do I test for / across many endpoints? Automate cross-role replay: capture reference responses under one role and replay them under others, diffing for leaked objects. Pentrova’s Authorization Matrix does this across every endpoint and role automatically.
Read the Authorization Matrix walkthrough for the testing method, or start a free engagement.