What is BOLA?
BOLA stands for Broken Object Level Authorization.
BOLA, or Broken Object Level Authorization, is a flaw in which an API accepts a request for a specific object without checking that the caller is entitled to that object — letting an authenticated user read or modify another user's data by changing an identifier.
In depth
Understanding BOLA
It is the first entry in the OWASP API Security Top 10 for a reason: it is simultaneously the most common API flaw and the most damaging, because a single missing check usually exposes every record of that type rather than one.
The mechanics are unglamorous. An endpoint like /api/invoices/1043 reads the identifier, fetches the record, and returns it. Authentication passes — the caller is a real logged-in user. Authorization for that particular object is never performed. Changing 1043 to 1044 returns somebody else's invoice.
BOLA resists the tools most teams already own. There is no malicious payload to match, no anomalous character sequence, and the response is a normal 200. Detecting it requires two authenticated identities and an attempt to cross the boundary between them, which is behavioural testing rather than signature matching. The older term IDOR describes the same failure.
In RedStrike
How RedStrike handles BOLA
RedStrike runs dedicated object-level authorization testing as a registered tool in the scan engine, establishing authenticated sessions for multiple roles and tenants and attempting cross-boundary access against discovered endpoints. It is tested alongside broken function-level authorization (OWASP API5), mass assignment and object-property over-exposure (API3), authentication bypass, and multi-step workflow bypass.
FAQ
Frequently asked questions
Common questions about BOLA.
What is the difference between BOLA and IDOR?
They describe the same failure. IDOR — Insecure Direct Object Reference — is the older term from the web application era. BOLA is the name OWASP gave it in the API Security Top 10, where it is category API1. If a document uses one term, it means the other.
Why do scanners miss BOLA?
Because nothing about the request is malformed. The attacker is authenticated, the identifier is well-formed, and the server returns a normal success response. Finding it requires knowing which object belongs to which identity, which means testing with at least two real sessions rather than matching a pattern in one.
How do you prevent BOLA?
Enforce the ownership check at the data-access layer rather than in each handler, so a new endpoint inherits it by default instead of needing a developer to remember. Unguessable identifiers reduce casual exploitation but are not a control — they are obscurity, and enumeration or a leaked identifier defeats them.
See BOLA in practice
Run continuous, verified security testing across your applications, APIs, and cloud accounts.