Broken Object Level Authorization occurs when an application fails to verify that a user is permitted to act on a specific object. It is closely related to IDOR, but the core issue is authorisation logic, not the visible object reference itself.
Expanded Definition
Broken Object Level Authorization, or BOLA, is a failure in application authorization where a user can reach or modify an object they should not control. The object may be a record, account, file, transaction, device, API resource, or NHI-related asset such as a service credential. The key issue is not how the object is named or referenced, but whether the application checks object-level permission before processing the request.
Definitions vary across vendors and standards bodies, but the security concern is consistent: if the server trusts a client-supplied object identifier without enforcing ownership or policy, unauthorized access follows. That makes BOLA especially common in API-driven systems, mobile back ends, and microservices where direct object access is routine. The concept aligns most closely with NIST Cybersecurity Framework 2.0 governance around access control and data protection, even though NIST does not use the BOLA label itself.
BOLA is often discussed alongside IDOR, but they are not identical in emphasis. IDOR describes exposure of an indirect reference that can be manipulated, while BOLA describes the authorization failure that allows the action to succeed. The most common misapplication is treating BOLA as a front-end input problem, which occurs when teams validate object IDs in the UI but fail to enforce object-level checks on the server.
Examples and Use Cases
Implementing object-level authorization rigorously often adds policy checks, data access mapping, and testing overhead, requiring organisations to weigh stronger isolation against lower development speed.
- An API lets one customer retrieve another customer’s invoice by changing the invoice ID in the request path.
- A self-service portal allows a user to update another employee’s profile because the backend checks only that the user is authenticated, not that they own the record.
- A cloud management tool exposes snapshot metadata and permits deletion of a snapshot belonging to a different tenant when the object identifier is guessed.
- An identity platform permits one service account to read another service account’s secrets reference because the authorization layer does not validate object ownership before returning the response.
- Security testers use guidance from the OWASP API Security Top 10 to confirm whether requests are blocked when object references are changed across users or tenants.
In practice, BOLA frequently appears in REST and GraphQL APIs, where resource IDs are easy to guess, enumerate, or reuse across sessions. It also shows up in agentic systems that can act on behalf of a user or service, because tool calls may carry object identifiers without a sufficiently strict authorization context. That is why object checks need to happen at the point of data access, not only at session creation or login.
Why It Matters for Security Teams
BOLA is one of the clearest examples of how a valid login can still produce a serious breach. If security teams miss object-level authorization, they may assume access control is working while attackers quietly pivot across accounts, tenants, or records. That creates exposure of personal data, business records, and privileged functions, and it can also undermine NHI governance when service identities or automation accounts are allowed to touch objects outside their intended scope.
The most effective defenses combine server-side ownership checks, deny-by-default policy design, test coverage for cross-object access, and logging that makes abnormal object access visible. Mapping those practices to OWASP authorization guidance and the access-control intent of NIST CSF helps teams move from general authentication success to per-object enforcement. BOLA also matters in API security programs because it is often invisible until an investigation reveals that the same endpoint served different data to different users without any alert.
Organisations typically encounter the impact only after a customer report, incident review, or red-team exercise exposes unauthorized object access, at which point BOLA becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | BOLA is an access-control failure that maps to enforcing authorized use of resources. |
| OWASP Agentic AI Top 10 | Agentic systems can trigger BOLA when tools act on objects without strict authorization context. | |
| OWASP Non-Human Identity Top 10 | NHI workflows expose BOLA when service identities can access objects beyond intended scope. |
Enforce object-level authorization checks and deny-by-default access across all application resources.
