Broken Object-Level Authorization (BOLA) in APIs: How to Find and Fix IDOR

CyberInsights Today · Educational bulletin · By Harpreet Singh
Sources checked November 8, 2026. OWASP documents BOLA in its 2023 API Security Top 10. This bulletin covers a vulnerability class. A disclosure date, affected or fixed versions, CVE, CVSS score and exploitation status apply to a specific incident or product advisory.

Summary. A user can be allowed to open an invoice screen and still be forbidden from opening a particular invoice. If your API checks the login but skips that second decision, another customer's records could be exposed or changed.

What goes wrong

Authentication establishes who is calling. Authorization decides what that caller can do. An object is a record or resource such as an invoice, file, or support ticket. Broken object-level authorization (BOLA) happens when the API accepts a reference to an object and fails to check the caller's permission for the requested action on that exact object. Insecure direct object reference (IDOR) is a common way this flaw appears. OWASP API Security Top 10, OWASP IDOR Prevention Cheat Sheet

Picture a billing portal with two customer accounts. A regular user from the first customer is allowed to use the invoice API. If the user can obtain a reference to an invoice belonging to the second customer and the endpoint loads it by reference alone, the request may expose the second customer's invoice. References can appear in links, request bodies, exports, or other API responses. A random identifier makes blind guessing harder. The authorization decision is still required every time the object is used. OWASP IDOR Prevention Cheat Sheet

Conceptual diagram. An invoice request crosses a customer boundary. The example uses fictional accounts.

Signed-in Customer A user → requests a Customer B invoice

• Vulnerable path. Check the session → look up the invoice by reference → return Customer B’s invoice.
• Protected path. Check the session → check permission for this invoice and action → deny before returning data.

Check your exposure and set a priority

Start with endpoints that accept an object reference. Include downloads, exports, nested resources, bulk actions and background jobs. Check whether each handler uses trusted identity and tenant context from the session or token, enforces the intended role and action, and scopes the object lookup or performs an equivalent policy check. Review endpoints across supported deployments and API versions. A single route that skips the shared check is enough to expose a record. OWASP API Security Top 10

Prioritize cross-customer access to sensitive records and actions that change or delete data. A readable invoice can disclose commercial or personal information. Unauthorized changes can corrupt billing records or disrupt operations. Consider what the caller can reach, how easily references are exposed, and how many records or tenants are in scope. An incident conclusion requires evidence from the affected environment.

Contain the exposure and fix the authorization check

1. Contain first. If you confirm a public-facing route exposes protected records, disable the affected action or restrict it to an authorized administrative workflow while you deploy the fix. Confirm the control also covers aliases and alternate clients. Rate limits can slow enumeration while containment is in place.
2. Enforce the rule on the server. Default to denial and evaluate the authenticated identity, the requested action and the specific object. Scope data access to the caller's allowed tenant and records. Where sharing or delegation is supported, enforce those rules explicitly. Apply the same policy to downloads and asynchronous workers, including when they generate or serve the result. OWASP API Security Top 10
3. Deploy to every affected path. For your own API, release the code or policy fix across every live version. For a third-party product, use its advisory to identify the supported fixed build. An edge block can buy time while you deploy the application fix.

Investigate and verify

Correlate application audit logs, gateway request IDs and backend access or mutation records. Look for a caller repeatedly trying distinct object references and for successful requests involving records outside the caller's permissions at the time. Account for legitimate delegates and service accounts. Denials can show attempted access. An HTTP success alone is also insufficient because the response may contain an error or empty result. Compare it with the authorization decision and evidence of actual data return or state change. Preserve available evidence without collecting tokens or full sensitive response bodies.

In an authorized test environment, create synthetic records under two test tenants. Confirm the intended owner can read and update its record, an ordinary user in the other tenant cannot do either, and an explicitly authorized delegate can only perform its allowed actions. Repeat for list, download, bulk and background paths. Check response bodies, stored state and audit events. After deployment, confirm every production instance runs the corrected release and repeat a limited approved smoke test with test records. Add these checks to the regression suite. OWASP IDOR Prevention Cheat Sheet

Takeaway. For each operation, ask whether this caller can perform this action on this exact record. Verify both the allowed and denied paths before closing the issue.

More in CyberInsights Today.

References

• OWASP API1:2023 — Broken Object Level Authorization explains the failure, its potential effects and the endpoint-level authorization requirement.
• OWASP IDOR Prevention Cheat Sheet covers scoped lookups, identifier complexity and verification.