What BOLA and IDOR Mean in API Security

Broken Object Level Authorization, or BOLA, occurs when an API accepts an object reference but does not enforce the correct access decision for the authenticated caller. OWASP ranks BOLA as API1:2023 because APIs routinely expose identifiers for accounts, orders, files, devices, messages, records, projects, tenants, and other business objects.

Insecure Direct Object Reference, or IDOR, describes a common pattern in which a user-controlled reference points directly to an object and changing that reference reaches data or actions outside the caller's authorization. In API discussions, IDOR is best understood as one way BOLA becomes exploitable. BOLA is the missing authorization decision; IDOR is the controllable reference that helps expose it.

BOLA vs IDOR, BOPLA, BFLA, and Broken Authentication

Authorization findings are often grouped together even though the required fix is different. The fastest way to improve triage is to identify whether the failure concerns an identity, an object, a property, or a function.

These weaknesses can overlap. An endpoint may correctly identify the user, fail to authorize the selected object, and then return properties the caller should never receive. Accurate classification matters because fixing only the token, route, or response shape will not repair the missing object-level decision.

Why BOLA and IDOR Reach Production

BOLA is rarely caused by a single unusual programming mistake. It usually appears when authorization rules are distributed across controllers, services, database queries, gateway policies, mobile clients, background jobs, and microservices. One path enforces ownership while another assumes an earlier layer already did it.

Practical BOLA and IDOR API Examples

The examples below focus on the authorization decision rather than exploit mechanics. They show where an API must connect identity, tenant, relationship, object, action, and current business state.

Customer invoices and statements

A customer requests an invoice by identifier. The API verifies the access token but retrieves the invoice from a global table without restricting the query to the customer's account. The correct control is not an unpredictable invoice number; it is a server-side rule that proves the invoice belongs to an account the caller may access.

Multi-tenant projects and files

A user belongs to tenant A but submits a project or file identifier from tenant B. Tenant context in the URL or token is not enough if the object lookup is not also restricted to the same tenant. Every nested resource must inherit and re-check the tenant boundary.

Batch and export endpoints

An endpoint accepts a list of record identifiers and returns a combined export. Authorizing the endpoint once is insufficient. The API must authorize each object in the collection, define whether partial results are permitted, and avoid revealing which unauthorized objects exist.

GraphQL nodes, edges, and nested resolvers

A top-level query may be authorized while a nested resolver returns a node from another account. Authorization must be enforced consistently on both graph edges and the nodes they resolve, including mutations and indirect references.

Support and delegated access

A support agent may be allowed to view a customer record only during an active case, from an approved role, and with an auditable reason. Static ownership checks may be too simple; relationship-based or attribute-based authorization can better express temporary delegation.

Machine-to-machine operations

A background worker or integration token may be authorized for one customer, region, device group, or data class. Service identity must be mapped to object scope rather than treated as an unrestricted internal superuser.

How to Test Object-Level Authorization Safely

The OWASP Web Security Testing Guide recommends verifying that users can interact only with objects they are authorized to access. Testing should be performed only in an authorized environment and with records created for the test.

1. Define the object and action matrix. List important objects and the read, create, update, delete, export, share, approve, and administrative actions that apply to them.
2. Create controlled identities. Use at least two standard users, separate tenants, and relevant privileged roles. Include service identities when machine-to-machine APIs are in scope.
3. Create synthetic objects. Use test records with no real customer information. Record which identity owns or may access each object.
4. Verify allowed cases first. Confirm legitimate access so test failures are not confused with broken functionality.
5. Verify denied cases. Test cross-user, cross-tenant, wrong-role, expired-delegation, and invalid-workflow relationships across each method and channel.
6. Cover indirect paths. Include nested resources, batch operations, GraphQL fields, exports, background tasks, mobile endpoints, alternate API versions, and partner routes.
7. Check the complete response. A correct denial should not disclose protected fields, object existence, internal identifiers, or sensitive error detail.
8. Add regression tests. Convert the authorization matrix into repeatable tests so refactoring and new API versions do not silently remove a check.

Runtime Signals That Can Reveal Object Authorization Abuse

Runtime monitoring cannot replace authorization in application code, but it can reveal missed checks, production-only paths, slow enumeration, compromised accounts, and attacks that static tests did not model. Strong detection combines several weak signals rather than treating every changed identifier as malicious.

Good telemetry records the authorization-relevant facts without copying secrets or full personal records into the security pipeline. Useful fields include caller ID, role, tenant, object type, normalized endpoint, method, relationship result, decision, response classification, trace ID, first and last seen time, and the reasons that raised risk.

event_type: object_authorization_anomaly
caller_id: user_1042
caller_tenant: tenant_a
endpoint: /api/invoices/{invoice_id}
method: GET
object_type: invoice
object_tenant: tenant_b
authorization_decision: unexpectedly_allowed
response_status: 200
response_classification: financial_record
risk_reasons:
  - cross_tenant_object_access
  - unusual_object_diversity
  - successful_response
recommended_action: investigate, contain if confirmed, repair authorization

How to Prevent BOLA and IDOR

The OWASP Authorization Cheat Sheet emphasizes deny-by-default behavior and validating permission on every request. Prevention works best when object authorization is a first-class application service rather than scattered conditional logic.

NIST SP 800-228, updated in March 2026, organizes API controls across the lifecycle. That lifecycle view is useful for BOLA: design the policy, implement and test it, deploy it consistently, observe real behavior, and feed incidents and exceptions back into engineering.

Testing, Gateways, and Runtime Protection Have Different Jobs

A mature program uses these controls together. The application remains responsible for the authorization decision. Runtime controls help discover coverage gaps, prioritize confirmed exposure, and reduce the time between first abuse and containment.

How to Investigate and Respond to a Suspected BOLA Incident

1. Preserve scoped evidence. Retain request metadata, trace IDs, relevant authorization decisions, and masked response classifications. Avoid copying full sensitive payloads into tickets.
2. Confirm the expected relationship. Ask the owning product team whether the caller was authorized by ownership, role, delegation, consent, tenant membership, or workflow state.
3. Measure affected objects. Determine which object types, endpoints, API versions, identities, tenants, and time ranges are involved.
4. Separate attempts from exposure. Distinguish denied requests from successful access and identify whether protected data was returned or changed.
5. Contain carefully. Revoke compromised identities, disable a vulnerable route, add a temporary policy, or limit a feature when the evidence supports it and business impact is understood.
6. Repair the authorization path. Add the missing server-side decision and review equivalent read, write, delete, export, batch, GraphQL, and legacy routes.
7. Notify the right owners. Include application, security, privacy, legal, and customer-response teams when the affected data or jurisdiction requires it.
8. Add regression coverage. Turn the incident relationship and alternate paths into automated tests and runtime detections.

A Five-Phase BOLA Risk-Reduction Plan

BOLA and IDOR API Security Evaluation Checklist

Use this checklist for architecture reviews, security testing, and API security platform evaluations. A product should make the authorization context clearer, not replace the application's responsibility to enforce it.

Common BOLA Prevention Mistakes

• Assuming a valid token authorizes every referenced object.
• Using UUIDs, hashes, or encoded identifiers as the main protection.
• Checking ownership for GET but not update, delete, export, or share actions.
• Authorizing the endpoint once but not every object in a batch.
• Trusting tenant IDs, owner IDs, or role fields supplied by the client.
• Applying different rules in REST, GraphQL, mobile, partner, and legacy API paths.
• Logging full protected responses as evidence of the vulnerability.
• Blocking an anomaly before documenting legitimate delegations and exceptions.
• Treating runtime monitoring as a substitute for repairing authorization in code.

Primary References

• OWASP API1:2023 — Broken Object Level Authorization
• OWASP WSTG — API Broken Object Level Authorization Testing
• OWASP IDOR Prevention Cheat Sheet
• OWASP Authorization Cheat Sheet
• NIST SP 800-228 — Guidelines for API Protection for Cloud-Native Systems

Conclusion

BOLA and IDOR API security begins with one precise rule: every action on every object must be authorized for the current caller and context. Identity alone is not permission, an identifier is not a policy, and a successful response is not proof that access was legitimate.

The strongest program combines explicit authorization design, caller-scoped data access, repeatable negative tests, consistent coverage across API channels, safe runtime visibility, and incident workflows that return lessons to engineering. That approach reduces both the likelihood of exposure and the time needed to recognize and contain authorization abuse that reaches production.

Frequently Asked Questions