Cybersecurity glossary
What is Broken Object-Level Authorization (BOLA)?
Learn what Broken Object-Level Authorization (BOLA) is, how object ID tampering leads to data breaches, how it relates to IDOR, and how to enforce per-object access checks in APIs.
Definition
Broken Object-Level Authorization (BOLA) is an API vulnerability where the server fails to verify that the authenticated caller is allowed to access or modify a specific object referenced by an identifier—enabling attackers to read or change other users’ resources by substituting object IDs.
Why BOLA matters
APIs are object graphs exposed over HTTP. Every orderId, documentId, and accountId is a handle an attacker can swap. Broken Object-Level Authorization (BOLA) is what happens when the server trusts those handles without proving the caller may touch that object.
It remains API Security Top 10 #1 for a reason: authentication is widespread; precise authorization is not.
Common BOLA patterns
Path ID swap
Change /orders/123 to /orders/124 with the same bearer token.
Body ID tampering
POST bodies reference another user’s resource identifiers.
Nested object access
Parent checks pass while child resources skip ownership validation.
Cross-tenant reads
Multi-tenant IDs cross organizational boundaries without tenant checks.
How a BOLA exploit unfolds
Create or obtain two identities
Establish victim and attacker accounts in the same environment.
Collect victim object IDs
Capture IDs from attacker-visible links, exports, or predictable sequences.
Replay with attacker credentials
Call get/update/delete endpoints using victim IDs.
Confirm unauthorized success
Unexpected 200 responses prove missing object checks.
Enumerate at scale
Script ID ranges or UUID lists to mass-exfiltrate objects.
Extend to writes
Modify or delete victim resources if mutations are also unchecked.
Authorization checks that stop BOLA
| Server check | Purpose |
|---|---|
| Authenticate caller | Establish subject identity (necessary but not sufficient) |
| Load object server-side | Never trust client claims about ownership |
| Compare owner/tenant to subject | Prove this user may access this object |
| Enforce action permission | Distinguish read vs update vs delete rights |
| Return generic 404/403 | Avoid leaking existence of unauthorized objects when policy requires |
BOLA prevention checklist
- Require object-level authorization on every ID-driven read and write.
- Centralize access policies (RBAC/ABAC) instead of ad-hoc if statements.
- Bind queries to tenant and owner constraints in the data layer.
- Add automated two-user BOLA tests for each new resource endpoint.
- Do not treat UUID obscurity as authorization.
- Review GraphQL and nested REST resources for skipped child checks.
- Log authorization denials for enumeration detection.
- Include BOLA cases in code review checklists for new APIs.
The practical takeaway
BOLA means the API authenticated someone, then forgot to ask whether this object is theirs. Fix it with mandatory per-object authorization tied to the verified subject and tenant.
If function roles or field-level writes are also weak, continue with BFLA and BOPLA.
Related security terms
Insecure Direct Object Reference (IDOR)
Classic name for the same class of object-reference authorization failures.
Broken Function-Level Authorization (BFLA)
Function/role failures rather than per-object access failures.
Broken Object Property-Level Authorization (BOPLA)
Property-level read/write authorization gaps inside objects.
Subject Claim (sub)
Authenticated identity that object checks must bind to.
Excessive Data Exposure
Often pairs with BOLA when responses overshare object fields.
Frequently asked questions
What is BOLA in simple terms?
You are logged in, but the API does not check that a record belongs to you. Changing an ID in the URL or body lets you open someone else’s data.
Is BOLA the same as IDOR?
They describe the same core failure. BOLA is the OWASP API Security term; IDOR is the classic application-security name.
Why is BOLA so common in APIs?
APIs expose object IDs everywhere for pagination and linking. Developers authenticate requests but forget per-object ownership checks.
What is a typical BOLA impact?
Mass retrieval or modification of other tenants’ orders, messages, documents, or personal data—often automatable.
Do random UUIDs fix BOLA?
Obscurity slows naive guessing but is not authorization. Predictable or leaked IDs still require server-side access checks.
How do you test for BOLA?
Create two users, gather object IDs for user A, and attempt access with user B’s session across every object endpoint.
Is tenant isolation part of BOLA?
Yes. Cross-tenant object access in multi-tenant APIs is a high-impact BOLA variant.
References
Explore authoritative guidance and frameworks related to broken object-level authorization (bola).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.