Category: API Security
Broken Object Level Authorization
Also known as: BOLA, Insecure Direct Object Reference, IDOR
Simply put
Broken Object Level Authorization is a security vulnerability where an application or API fails to properly verify that a requesting user is permitted to access a specific data object. An attacker can exploit this by manipulating object identifiers in requests to retrieve or modify data belonging to other users. It is widely considered among the most critical and common vulnerabilities affecting APIs.
Formal definition
BOLA occurs when an API endpoint accepts a client-supplied identifier (such as a resource ID in a URL path, query parameter, or request body) and retrieves or operates on the corresponding object without performing adequate server-side validation that the authenticated principal is authorized to access that specific object instance. Object-level authorization checks are typically implemented at the code level, and their absence or inconsistent application allows an attacker to substitute identifiers to access arbitrary objects outside their intended authorization scope. Exploitation may result in unauthorized data disclosure, data manipulation, or privilege escalation. The vulnerability is distinct from function-level authorization failures, as it concerns per-object access decisions rather than access to API functionality broadly.
Why it matters
Broken Object Level Authorization is consistently ranked as the most critical vulnerability in the OWASP API Security Top 10, and its prevalence reflects a fundamental challenge in API design: every endpoint that exposes a resource identifier creates a potential access control decision point. When those decisions are absent or inconsistently applied server-side, attackers can enumerate or manipulate identifiers to reach data that was never intended to be accessible to them. The consequences typically include unauthorized data disclosure, data manipulation, and in some cases privilege escalation.
Who it's relevant to
API Developers
Developers building APIs must implement object-level authorization checks consistently on every endpoint that accepts a resource identifier, rather than relying on authentication alone. Missing or inconsistent checks at the code level are the direct cause of BOLA, making this a core concern during implementation and code review.
Application Security Engineers
Security engineers reviewing API designs or conducting threat modeling need to identify every endpoint that exposes object identifiers and verify that server-side authorization logic is applied per object, per request. Static analysis tools can flag missing authorization patterns in some cases, but fully validating BOLA mitigations typically requires runtime testing with realistic user context.
Penetration Testers and Bug Bounty Researchers
BOLA is a high-yield target in API penetration testing and bug bounty programs because exploitation often requires only a valid account and the ability to substitute identifiers in requests. Testers typically probe URL path parameters, query parameters, and request body fields with identifiers belonging to other test accounts to confirm whether unauthorized access is possible.
Security Architects
Architects designing systems that expose APIs must consider how object identifiers are structured and surfaced to clients, since predictable or sequential identifiers lower the effort required for exploitation. Architectural decisions around indirect reference maps, randomized identifiers, and centralized authorization services can reduce BOLA risk before implementation begins.
Product and Engineering Leaders
Because BOLA can result in unauthorized access to user data across an entire platform, the vulnerability carries significant regulatory and reputational risk. Leaders overseeing products with API-driven architectures should ensure that authorization testing is part of the standard development and release process, not treated as an optional security audit activity.
Inside BOLA
Object-Level Permission Check
A validation step performed server-side that confirms the authenticated requesting user has explicit authorization to access or manipulate the specific object instance identified in the request, not merely that the user is authenticated.
Object Identifier
A reference such as a numeric ID, UUID, slug, or other value included in a request that points to a specific resource or data record. In BOLA vulnerabilities, these identifiers can typically be manipulated by an attacker to target objects belonging to other users.
Ownership or Relationship Binding
The association between a user and a resource that authorization logic must verify at request time, confirming that the requesting user owns, is permitted to view, or has a defined relationship to the target object.
Horizontal Privilege Escalation
The access pattern that BOLA most commonly enables, where a user at the same privilege level accesses another user's objects without elevated role permissions, distinguishing it from vertical privilege escalation.
Server-Side Authorization Enforcement
The requirement that authorization checks be performed on the server rather than relying on client-side controls such as hidden fields, UI element visibility, or client-enforced access restrictions, which attackers can bypass.
Indirect Object Reference
A design pattern where the application maps user-facing identifiers to internal resource references, reducing but not eliminating BOLA risk if server-side checks are still absent or insufficient.
Common questions
Answers to the questions practitioners most commonly ask about BOLA.
Does authentication guarantee that object-level authorization is handled correctly?
No. Authentication confirms who a user is, but it does not enforce what objects that user is permitted to access. BOLA vulnerabilities occur when an application authenticates a request successfully but then fails to verify whether the authenticated user has permission to access the specific object identified in the request. A fully authenticated user can still exploit BOLA by supplying identifiers belonging to other users' objects.
If an API endpoint requires a valid token or session to access, is it protected against BOLA?
Not necessarily. Requiring authentication is a prerequisite for authorization but is not a substitute for it. BOLA arises after authentication succeeds, at the point where the application resolves an object identifier from the request. If the application retrieves the object matching that identifier without confirming the requesting user owns or has explicit permission to access it, the endpoint is vulnerable regardless of whether a valid token was required to reach it.
How should authorization checks for object access typically be implemented in an API?
The recommended approach is to perform an explicit ownership or permission check at the data access layer for every request that resolves an object by identifier. This typically means querying for the object using both the object identifier and the authenticated user's identity as filter conditions, so that a record is returned only if it belongs to or is permitted for that user. Relying solely on the identifier supplied in the request without this secondary constraint is what produces the vulnerability.
What role do indirect or unpredictable object identifiers play in BOLA risk?
Using non-sequential or opaque identifiers, such as UUIDs, reduces the ease with which an attacker can guess valid identifiers belonging to other users, but it does not eliminate BOLA risk. If the authorization check itself is absent, an attacker who obtains a valid identifier through other means, such as interception, leakage in another response, or enumeration via a separate flaw, can still access the object. Unpredictable identifiers are a defense-in-depth measure, not a replacement for proper authorization logic.
How can BOLA vulnerabilities be detected during testing?
Testing typically involves authenticating as two or more distinct users and then attempting to access objects belonging to one user while authenticated as another, using identifiers observed in legitimate responses. If the application returns the object rather than a 403 or equivalent rejection, a BOLA vulnerability is present. Automated scanning tools may surface candidate endpoints but generally cannot confirm exploitability without understanding the application's data ownership model, so manual testing with multiple test accounts is usually necessary to achieve adequate coverage.
Are BOLA vulnerabilities limited to REST APIs, or do they appear in other interface types?
BOLA vulnerabilities are not limited to REST APIs. They can appear in any interface that accepts a user-supplied identifier and resolves it to a backend object, including GraphQL queries, SOAP services, WebSocket messages, and traditional web application parameters. The common factor is the absence of a per-request check confirming that the authenticated caller is authorized to access the specific object being resolved, regardless of the transport or interface style in use.
Common misconceptions
Using unpredictable or random object identifiers such as UUIDs prevents BOLA vulnerabilities.
Non-sequential or opaque identifiers raise the difficulty of guessing valid object references but do not constitute authorization. If the server does not verify that the requesting user is permitted to access the identified object, an attacker who obtains a valid identifier through leakage, enumeration, or other means can still exploit the vulnerability.
Authentication and role-based access control are sufficient to prevent BOLA.
Authentication confirms identity and role-based controls restrict access by user type, but neither mechanism typically validates whether a specific authenticated user is authorized to access a specific object instance. BOLA occurs at the object level, requiring per-request ownership or relationship checks that role checks alone do not provide.
BOLA only affects REST APIs using numeric identifiers in URL paths.
BOLA can appear in any API style or transport mechanism, including GraphQL queries, POST request bodies, WebSocket messages, and SOAP parameters. The identifier format and its position in the request are irrelevant to whether the underlying authorization check is present or absent.
Best practices
Implement server-side authorization checks on every request that accesses an object, verifying that the authenticated user has an explicit and validated relationship to the specific object being requested rather than assuming access based on authentication status alone.
Centralize object-level authorization logic in a shared, reusable component or middleware layer so that checks are applied consistently across all endpoints rather than relying on developers to implement them individually per endpoint.
During code review and security testing, treat every API endpoint that accepts an object identifier as a potential BOLA surface and verify that an ownership or permission check is present and correctly enforced for each one.
Use automated integration and API security tests that send requests with identifiers belonging to a different test user's objects and assert that the server returns an authorization error rather than the requested data.
Avoid relying on indirect object references, UUID identifiers, or client-side access controls as substitutes for server-side authorization, and document explicitly that these measures do not replace per-object permission verification.
Apply the principle of least privilege when designing data access layers, ensuring that queries are scoped to the requesting user's permitted objects by default rather than fetching all records and filtering results after retrieval.