What Is BOLA? (And How It Differs From IDOR)
BOLA is the number one API security risk, and it is constantly confused with IDOR. Here is what it is, how the two relate, a concrete example, and how to prove and prevent it.
What is BOLA?
BOLA stands for Broken Object Level Authorization. It happens when an API endpoint returns or modifies an object based on an identifier in the request, without verifying that the authenticated caller is actually allowed to access that specific object. The API answers “are you logged in?” but forgets to ask “is this yours?”
It sits at the very top of the OWASP API Security Top 10 as API1 — the single most common and damaging API vulnerability, because object identifiers are everywhere and the missing check is so easy to overlook.
What is IDOR?
IDOR stands for Insecure Direct Object Reference. It’s the classic term (CWE-639) for exposing a direct reference to an internal object — a database ID, a filename, a key — and letting a user manipulate that reference to reach objects they shouldn’t. IDOR predates modern APIs and covers web apps, files and parameters, not just API objects.
BOLA vs IDOR: the difference
Here’s the part everyone searches for. The honest answer: they describe the same root cause — a missing per-object authorization check — but from two eras and two scopes. IDOR is the original, broad umbrella term. BOLA is the newer, API-specific name OWASP introduced for object-level authorization failures in APIs.
Put simply: every BOLA is an IDOR, but IDOR is the wider family. In day-to-day use, security professionals treat them as synonyms — if someone says “IDOR in the API,” they mean BOLA.
| BOLA | IDOR | |
|---|---|---|
| Full name | Broken Object Level Authorization | Insecure Direct Object Reference |
| Origin | OWASP API Security Top 10 (API1) | OWASP classic / CWE-639 |
| Focus | Object-level authorization in APIs | Any direct reference to an object |
| Scope | Narrower, API-centric | Broader, historical umbrella term |
| Root cause | Missing per-object auth check | Missing per-object auth check |
| Relationship | A modern, API-specific case of IDOR | The original, general term |
A concrete example
You log in to a shop and open your order. The API call looks like this:
GET /api/orders/123 → 200 OK (your order) GET /api/orders/124 → 200 OK (someone else's order)
You only changed the ID from 123 to 124. If the server hands back a different customer’s order, that’s BOLA: you were authenticated, but the endpoint never checked that order 124 belongs to you. Swap it for /api/users/{id}/card and the same flaw leaks payment data.
Why BOLA is so common (and dangerous)
Modern apps are thousands of API endpoints, each taking object IDs. Authentication is centralized and easy; per-object authorization is per-endpoint and easy to forget. One new route that trusts the ID is all it takes. And because the request looks completely normal, BOLA rarely trips logging or WAFs — it’s just a valid user asking for a valid-looking object.
How to detect BOLA (and why scanners miss it)
BOLA is a logic flaw, not a signature, so template scanners largely miss it. Proving it means demonstrating that one identity can access another identity’s object — which requires two controlled accounts and a way to be certain the object really crossed the boundary, not just that a request returned 200.
This is exactly how PenStrike’s access-control prover works: it seeds a unique sentinelin one account’s object, then proves a second identity can read it back — a real cross-object demonstration, not a similarity guess. See the full coverage.
How to prevent BOLA
- Check ownership on every object access, tied to the authenticated user, server-side.
- Deny by default. No explicit grant means no access.
- Centralize the check so a new endpoint can’t silently skip it.
- Use random, unguessable IDs (UUIDs) as defense in depth — never as the only control.
- Test it continuously with two accounts, because one refactor can reintroduce it.
FAQ
Is BOLA the same as IDOR?+
Almost. IDOR is the classic, broad term for accessing an object by manipulating its reference without an authorization check. BOLA is the modern, API-focused name OWASP uses for the same root cause at the object level. Every BOLA is an IDOR; not every IDOR is described as BOLA. In practice people use them interchangeably.
Why is BOLA the number one API security risk?+
Because APIs expose object identifiers everywhere (in URLs, bodies and parameters) and it is easy to check that a user is authenticated but forget to check they own the specific object they requested. That single missing check, repeated across endpoints, is the most common and most impactful API flaw.
What is an example of BOLA?+
A request like GET /api/orders/123 returns your order. Change the ID to GET /api/orders/124 and, if the server returns another user's order, that is BOLA: the endpoint authenticated you but never verified the order belongs to you.
How do you prevent BOLA?+
Enforce an authorization check on every object access, tied to the authenticated user, and deny by default. Never rely on unguessable IDs alone. Centralize the check so it cannot be forgotten on a new endpoint, and use random identifiers as defense in depth, not as the control.
Can a scanner find BOLA automatically?+
Signature scanners struggle, because BOLA is a logic flaw, not a pattern. Proving it requires showing that one identity can read or change another identity's object, on purpose, with a controlled second account. That is exactly what an autonomous proving agent does before reporting it.
Prove BOLA, don’t guess it
PenStrike proves broken access control by seeding a sentinel and reading it back across identities — no false positives. See the coverage or request access for your own authorized targets.