Broken Object Level Authorization is an API authorization flaw, not an authentication flaw. The request may come from a real, logged-in user with a valid token. The failure is that the backend does not verify whether that user is allowed to access the exact object named in the request.
BOLA in 30 Seconds
A simple way to think about it is:
Authentication: Who are you? Function authorization: May you use this operation? Object authorization: May you perform this operation on THIS object?
If the third check is missing or inconsistent, the API can be vulnerable even when authentication, JWT validation, API keys and route-level permissions are working correctly.
Most important control
Enforce object-level authorization server-side on every path that reads or changes a protected object.
Best regression test
Create data as User A, then verify User B cannot read, update, delete, download or export User A's objects.
Common misconception
UUIDs reduce guessability, but they do not make an unauthorized request authorized.
Runtime reality
Behavior analytics can surface suspicious object access, but application context is often needed to prove a BOLA violation.
Is BOLA Still OWASP API1 in 2026?
Yes. As of September 12, 2026, the current published OWASP API Security Top 10 edition remains the 2023 edition, where API1:2023 is Broken Object Level Authorization. OWASP describes BOLA as widespread and easy to exploit because object identifiers commonly appear in paths, query parameters, headers and request bodies.
OWASP also makes an important point that is easy to miss: comparing the user ID in a token with a request parameter is not a complete BOLA solution. Real authorization can depend on tenant membership, ownership, delegation, object relationships, role, workflow state and the action being performed.
NIST's API guidance is also newer than many older BOLA articles. NIST SP 800-228 now includes the March 13, 2026 update with appendices covering API risk categories and recommended controls across API lifecycle stages.
BOLA vs IDOR vs BFLA vs BOPLA
These terms are related, but they answer different security questions. Separating them makes design reviews and security findings much clearer.
| Term | Core question | Typical failure | Example |
|---|---|---|---|
| BOLA OWASP API1:2023 |
Can this caller access this exact object? | Missing or wrong object-level authorization | A user can request another tenant's invoice by changing the invoice reference |
| IDOR | Can a controllable reference reach an unauthorized object? | Direct object reference is trusted without sufficient authorization | Changing a document ID returns someone else's document |
| BFLA OWASP API5:2023 |
Can this caller invoke this function? | Function-level role or privilege check is missing | A standard user can call an admin-only operation |
| BOPLA OWASP API3:2023 |
Which properties of an allowed object may this caller read or change? | Property-level authorization is missing | A user can update an internal approval field on their own record |
| Broken authentication OWASP API2:2023 |
Is the caller's identity established correctly? | Identity, session or credential control is weak | A token flaw lets an attacker act as another user |
MITRE's CWE-639: Authorization Bypass Through User-Controlled Key explicitly describes the pattern of one user reaching another user's data by modifying a key and lists IDOR, BOLA and horizontal authorization as related terminology.
Where BOLA Appears in Real APIs
BOLA is not limited to numeric IDs in REST URLs. Any caller-controlled reference that selects or acts on a protected resource deserves an object-level authorization check.
| API pattern | Object reference | Authorization question | Why teams miss it |
|---|---|---|---|
| REST resource | /invoices/{invoice_id} |
May this principal access this invoice? | The route itself is valid for all authenticated users |
| GraphQL query or mutation | Node, document or record ID in variables | May this principal read or mutate the resolved object? | A single GraphQL endpoint can hide many object operations |
| File download | File ID, storage key or signed reference | May this caller retrieve this file now? | Static or storage-backed resources may bypass normal application checks |
| Bulk or export API | List of IDs, filter, report scope or job ID | Are all returned objects inside the caller's authorized scope? | One request can expose many objects at once |
| Multi-tenant SaaS | Tenant, workspace, organization or project ID | Does the object belong to an allowed tenant boundary? | Tenant ID may be accepted from the client instead of derived from trusted context |
| Support or delegated access | Customer, case, account or delegated resource | Is this support or delegated relationship valid for this action? | Relationship-based rules are more complex than simple roles |
Why UUIDs Do Not Fix BOLA
Random or unpredictable identifiers are useful defense in depth because they make blind guessing harder. OWASP recommends them, but also requires authorization checks for every function that uses client input to access a record. A UUID that leaks through logs, browser history, analytics, emails, shared links, mobile traffic or another API is still just an identifier. If the backend does not check authorization, possession of that UUID may be enough to reach the object.
How to Prevent Broken Object Level Authorization
The strongest BOLA defense puts authorization close to the protected data and makes it difficult for a developer to accidentally load an object outside the caller's scope.
| Control | What good implementation looks like | Common weak pattern |
|---|---|---|
| Object-level authorization | Check principal, action and object on every protected operation | Checking only that the user is authenticated |
| Scoped data access | Query by object ID and trusted tenant/owner scope where practical | Load any object by ID first and hope a later check happens |
| Deny by default | Access is denied unless policy explicitly allows it | Missing policy branch falls through to allow |
| Central authorization policy | Reusable policy helpers or policy engine with consistent semantics | Different endpoints reimplement ownership checks differently |
| Relationship or attribute context | Use tenant, owner, delegation, role, object state and other relevant attributes | RBAC alone is treated as sufficient for object ownership |
| Response minimization | Return only data needed for the workflow | Overly broad object serialization increases impact if access control fails |
| Authorization regression tests | Positive and negative cases run continuously in CI/CD | Authorization is tested only during occasional penetration tests |
Prefer Scoped Queries Over Fetch-Then-Check Where Possible
The safest design often ensures that unauthorized records are not returned from the data layer in the first place. The exact implementation depends on your architecture, but the pattern is straightforward:
// Risky pattern: object is selected only by caller-controlled ID invoice = findInvoiceById(request.invoice_id) return invoice // Safer pattern: scope the lookup to trusted authorization context invoice = findInvoice( id = request.invoice_id, tenant_id = principal.tenant_id ) if invoice is not found: deny access authorize(principal, "read", invoice) return minimumRequiredFields(invoice)
The second pattern is defense in depth: the data query narrows the object scope and an explicit policy check still validates the action. For complex relationships, OWASP's Authorization Cheat Sheet recommends considering attribute-based or relationship-based access control instead of relying only on simple role checks.
Do Not Trust Client-Supplied Tenant Context
When possible, derive tenant, organization, account or workspace scope from trusted server-side identity and entitlement data rather than accepting it as authoritative because it appears in a request header or body. If client-supplied scope is required, validate it against the authenticated principal before it influences a database query or downstream request.
For broader design work, see Ammune's API threat modeling guide and API security architecture design.
How to Test BOLA Safely
Authorization testing should be deliberate, repeatable and performed only in environments where you have permission. The highest-value BOLA regression test uses multiple identities and known ownership boundaries.
Two-User Negative Authorization Matrix
| Principal | Object | Read | Update | Delete | Download / export |
|---|---|---|---|---|---|
| User A | User A object | Allow if policy permits | Allow if policy permits | Allow if policy permits | Allow if policy permits |
| User A | User B object | Deny | Deny | Deny | Deny |
| Tenant A user | Tenant B object | Deny | Deny | Deny | Deny |
| Support / delegated user | Object outside delegated scope | Deny | Deny | Deny | Deny |
Run the matrix across every object-bearing access path: REST endpoints, GraphQL resolvers, mobile APIs, download routes, exports, batch operations, asynchronous jobs, admin/support interfaces and partner APIs.
What Should the API Return: 403 or 404?
Both patterns can be valid. A 403 Forbidden response clearly communicates that the request is understood but not allowed. A 404 Not Found response can reduce object-existence leakage when that matters to the threat model. What matters most is consistency with the API contract and that unauthorized access never returns the protected object or performs the protected action.
Make Authorization Tests a Release Gate
OWASP's current Authorization Regression Testing guidance recommends maintaining a machine-readable actor-resource-action policy matrix and running authorization regression tests continuously. That directly addresses the “Day 2” problem where a refactor, new endpoint, cache, resolver or data-layer change quietly breaks a previously correct authorization rule.
See also API security in CI/CD and can API security be solved in development?
Runtime Detection: What It Can and Cannot Tell You
Runtime visibility is valuable because BOLA abuse can look like normal API traffic: valid credentials, valid methods, valid JSON and successful responses. The useful signals are behavioral and contextual rather than simple signatures.
Object access breadth
A caller suddenly touches far more object IDs, tenants, accounts or records than its normal baseline.
Cross-tenant signals
Requests or responses indicate access across a tenant, workspace, customer or partner boundary.
Enumeration behavior
Sequential or high-volume object access suggests automated discovery even when requests return normal status codes.
Sensitive response exposure
Unusual calls return PII, financial data, documents, credentials, secrets or other high-value information.
Log Authorization Decisions, Not Just HTTP Status
Useful BOLA investigation data should help an analyst answer who requested what, under which policy, and why it was allowed or denied. Avoid logging secrets or unnecessary full PII.
Recommended authorization event fields: - timestamp and correlation / trace ID - route template and HTTP method - authenticated principal or pseudonymous principal ID - tenant / organization / workspace context - object type and privacy-safe object reference - requested action: read, update, delete, export, share, approve... - authorization decision: allow / deny - policy or rule identifier - response status and response data classification - API owner / service owner - anomaly or risk signal, if present
Structured events can be forwarded to a SIEM so the security team can correlate BOLA signals with authentication, endpoint, application and incident data. For operational design, see centralized SIEM log forwarding formats and API behavior analytics.
Which APIs Should You Review for BOLA First?
If the API estate is large, start where a single authorization failure would create the highest business impact. The following scoring model is an illustrative prioritization tool, not an OWASP or NIST standard.
| Risk factor | Points | Why it matters |
|---|---|---|
| Cross-tenant or cross-customer object access is possible | +3 | One defect can break a hard isolation boundary |
| Object contains high-sensitivity data | +3 | Raises confidentiality, privacy and regulatory impact |
| Endpoint can update, delete, approve, transfer, share or export | +2 | Impact extends beyond data viewing |
| Partner, internet-facing or high-volume API | +1 | Larger exposure and abuse opportunity |
| New, undocumented, legacy or rapidly changing endpoint | +1 | Authorization assumptions are more likely to drift |
Suggested interpretation: 7–10 points = review first; 4–6 = high priority; 0–3 = normal authorization review queue. Adjust the weights for your own threat model, data classification and business processes.
BOLA Remediation Workflow
Do not patch only the endpoint named in the finding. Authorization logic is often shared across related routes, versions, resolvers, exports and services.
1. Confirm the boundary
Identify the principal, object, action, tenant/owner relationship and the policy that should have blocked access.
2. Search for siblings
Review read, update, delete, export, download, admin, support, batch and partner paths that touch the same object.
3. Fix the design
Centralize or strengthen object authorization and scope data access so the same mistake is harder to repeat.
4. Add permanent tests
Convert the finding into negative regression tests and run them in CI/CD so the bug cannot quietly return.
Where Runtime API Security Helps — and Where Application Logic Still Matters
A runtime API security platform can add useful visibility around BOLA by discovering object-bearing APIs, baselining caller behavior, identifying unusual enumeration or cross-scope patterns, detecting sensitive data exposure, scoring risk and forwarding structured evidence to SIEM/SOC workflows.
That runtime layer should complement, not replace, the application's object-level authorization logic. A security product outside the business application may not know whether a specific user is contractually delegated to a customer, whether an approver may act on a record in its current state, or whether a support user has temporary entitlement to a particular account. Those decisions belong in authoritative application or policy context.
Ammune can help surface runtime API behavior and send security events to SIEM workflows, while engineering teams remain responsible for enforcing the underlying authorization policy in the application and service layer.
OWASP API1:2023 BOLA Prevention Checklist
| Check | Question | Target state |
|---|---|---|
| Object inventory | Do we know which endpoints accept account, customer, tenant, file, order, invoice, document, job or other protected object references? | Documented |
| Every-request authorization | Does every protected object operation check principal + action + object? | Required |
| Tenant isolation | Is tenant scope derived or validated from trusted server-side context? | Required |
| Deny by default | Does missing or ambiguous policy result in denial? | Required |
| Alternate access paths | Are GraphQL, export, file download, batch, async, admin, support and partner paths covered? | Required |
| Negative tests | Can User B prove they cannot read or modify User A's objects? | CI/CD gate |
| UUID assumption | Are random IDs treated only as defense in depth rather than authorization? | Yes |
| Authorization logging | Can investigators see principal, object type, action, policy decision and trace ID without exposing secrets? | Recommended |
| Runtime monitoring | Can the team detect enumeration, unusual object breadth, cross-tenant patterns and sensitive responses? | Recommended |
| Regression after fixes | Does every confirmed BOLA finding become a permanent automated test? | Required |
Authoritative Guidance and 2026 Freshness
This guide was reviewed against primary security sources on September 12, 2026. The most useful references are:
- OWASP API1:2023 Broken Object Level Authorization — current OWASP API Security Top 10 category definition, attack scenarios and prevention guidance.
- OWASP Authorization Cheat Sheet — least privilege, deny by default, every-request checks, authorization location, logging and test guidance.
- OWASP Authorization Regression Testing Cheat Sheet — current guidance for actor-resource-action matrices, horizontal escalation tests, tenant isolation and CI/CD gating.
- NIST SP 800-228, March 2026 update — API risks and recommended protections across development and runtime lifecycle stages.
- CWE-639 — authorization bypass through a user-controlled key, closely related to IDOR/BOLA patterns.
OWASP API Security Top 10 2023 remains the current published API-specific Top 10 edition as of this update. If OWASP publishes a newer API Top 10 edition, the category naming and ranking should be reviewed again rather than changing the page date without a substantive content update.
Frequently Asked Questions
What is OWASP API1:2023 Broken Object Level Authorization?
Broken Object Level Authorization, or BOLA, happens when an API accepts a request for a specific object but does not verify that the authenticated caller is allowed to access or act on that exact object.
Is BOLA the same as IDOR?
They overlap closely. IDOR describes a common manifestation in which a user-controlled object reference can be changed to reach another object. BOLA is the API-focused authorization category that covers failures to enforce access at the object level.
Do UUIDs prevent BOLA?
No. Random UUIDs make identifiers harder to guess, but they do not replace authorization. The server still has to verify that the caller is permitted to access the requested object on every relevant operation.
What is the difference between BOLA and BFLA?
BOLA is about access to the wrong object through a function the caller may legitimately use. BFLA is about access to a function or operation the caller should not be allowed to invoke, such as an administrative action.
How should developers test for BOLA?
Use at least two controlled users or tenants and verify that each user can access their own objects but cannot read, update, delete, download, export or otherwise act on the other user's objects. Run these negative authorization tests continuously in CI/CD.
Can an API gateway or WAF fix BOLA by itself?
Usually not. Gateways and runtime security controls can enforce coarse-grained policies and detect suspicious behavior, but object-level authorization normally depends on application or service context such as ownership, tenant membership, relationships and workflow state.
Can runtime monitoring detect BOLA?
Runtime monitoring can identify signals such as unusual object access, enumeration, cross-tenant patterns, repeated denials and sensitive responses. It is strongest when it also has identity, tenant and entitlement context; traffic patterns alone cannot always prove that access was unauthorized.
Should a denied BOLA request return 403 or 404?
Both can be appropriate depending on the application's threat model and API contract. A 403 clearly expresses denial, while a 404 can reduce information leakage about whether an object exists. The important requirement is that unauthorized access never succeeds.
Make object-access risk visible in production
Ammune helps teams discover APIs, analyze runtime behavior, identify sensitive-data exposure, investigate API abuse patterns and forward structured security events to SIEM workflows. These capabilities complement the object-level authorization controls that must be enforced by the application and services themselves.