BOLA (Broken Object Level Authorisation)

What is BOLA (Broken Object Level Authorization)?

Broken Object Level Authorization (BOLA) is a class of API vulnerabilities in which an application correctly verifies that a user is authenticated, but fails to verify that the user is authorized to access the specific data object they are requesting. It is consistently ranked as the most prevalent and most exploited of all API vulnerabilities, listed as API1 in the OWASP API Security Top 10 in both the 2019 and 2023 editions.

BOLA is sometimes referred to as Insecure Direct Object Reference (IDOR) in the context of web applications, though the two terms are not identical. BOLA is the API-specific formulation, and it accounts for how modern APIs expose object identifiers at scale across endpoints, services, and data models.

How BOLA works

APIs routinely expose identifiers that reference specific data objects:

• A user ID
• An order number
• An account reference
• A document ID
• A transaction identifier

When a client makes a request to retrieve or modify a specific object, the API uses that identifier to locate and return the relevant data.

BOLA vulnerabilities exist when the API does not verify, at the point of that request, that the authenticated user making the request is actually permitted to access the object identified. The API confirms who the user is. It does not confirm whether this user is allowed to see that object.

An attacker exploiting BOLA does not need to bypass authentication. They are already authenticated as a legitimate user. They manipulate or enumerate the object ID, incrementing a numeric ID, substituting a UUID, or replacing one user’s reference with another’s. The API returns the data without checking whether the requesting user owns or has rights to that specific object.

Here is a concrete Broken Object Level Authorization example:

1. A user is authenticated and requests their own order details at /api/orders/10482.
2. The API returns the order correctly.
3. The attacker changes the identifier to /api/orders/10483, another user’s order.
4. The API, having confirmed that the requester is authenticated, returns the second user’s order without checking whether the authenticated user has any relationship to order 10483.

Why BOLA is difficult to detect

BOLA is structurally invisible to most automated security tools for a specific reason: The API response to a successful BOLA attack looks identical to the response to a legitimate request.

When a user requests their own order and receives a 200 OK response with the order data, the HTTP response is indistinguishable from the response an attacker receives when they request another user’s order using the same endpoint:

• The status code is the same.
• The response format is the same.
• The data structure is the same.

Nothing in the observable HTTP exchange signals that anything has gone wrong.

Traditional scanners work by matching request-response patterns against known vulnerability signatures. There is no signature for BOLA. The flaw is not in the request or the response; it is in the absence of an authorization check that should have occurred between the two.

Detecting BOLA vulnerabilities requires understanding the application’s data model, creating controlled test objects with known ownership boundaries, making cross-ownership requests, and verifying whether unauthorized access was, in fact, blocked.

This is why BOLA is both the most common of API vulnerabilities and the one most frequently missed by an automated tool. Finding it requires adversarial reasoning about how the application is designed to work, not pattern-matching against how requests look.

Types of BOLA

BOLA manifests differently depending on how an API exposes and handles object identifiers.

Sequential numeric identifiers The simplest and most easily exploited form. Object identifiers are integers assigned in sequence, such as 1024, 1025, and 1026. An attacker needs no knowledge of the system to enumerate them. Incrementing or decrementing the identifier is sufficient to test whether access controls exist.

UUID and non-sequential identifiers APIs that use UUIDs or other non-sequential identifiers make enumeration harder, but do not eliminate BOLA. If an attacker can obtain a valid identifier belonging to another user - through a separate API response, a shared link, a sensitive data leak, or a reference in another object - the underlying authorization failure remains exploitable. Non-sequential identifiers reduce discoverability but do not fix the vulnerability.

Indirect object references Some APIs do not expose the underlying identifier directly but use a reference that maps to it, such as a slug, a short code, or a human-readable identifier. The authorization failure can exist at any layer of that reference chain.

Cross-tenant BOLA In multi-tenant applications, BOLA can allow unauthorized access by one tenant to objects belonging to another. The severity is typically higher because the data involved is often sensitive information, and the boundary being crossed is between organizations rather than between individual users.

BOLA vs. BFLA

BOLA and BFLA (Broken Function Level Authorization, API5 in the OWASP API Security Top 10) are related but distinct.

• BOLA is about data objects. The question is whether the user can access this specific piece of data. The endpoint and function are legitimate - the authorization failure is at the object level.
• BFLA is about functions and endpoints. The question is whether the user can perform this action or call this endpoint at all. An attacker exploiting BFLA is not trying to access another user’s data through a legitimate endpoint. Instead, they are calling an endpoint or triggering a function that should be restricted to a different role entirely, such as an administrative function that was never supposed to be accessible to standard users.

In practice, both can be present in the same application, and distinguishing them matters for how they are remediated. For instance, BOLA is fixed by implementing object-level authorization checks. In contrast, BFLA is fixed by implementing function-level access controls.

BOLA in the context of the OWASP API Security Top 10

BOLA has held the top position in the OWASP API Security Top 10 across both the 2019 and 2023 editions. This is not because it is the most technically sophisticated vulnerability. It is because it is structurally endemic to how APIs are built and because the testing methods that would reliably detect it are not part of standard automated scanning programs.

The 2023 edition of the OWASP API Security Top 10 also introduced Broken Object Property Level Authorization as a separate category (API3). It distinguishes between access to an entire object, which BOLA addresses, and access to specific properties within an object that should be restricted or read-only. These categories frequently co-occur in the same APIs.

BOLA and compliance

Regulatory frameworks often create direct obligations around authorization testing that BOLA sits within.

• PCI DSS v4.0 requires penetration testing of systems that handle cardholder and sensitive data and explicitly expects testing of access controls and authorization logic. APIs that process payment data and are vulnerable to BOLA represent a direct compliance exposure.
• DORA requires financial entities to test their ICT systems under realistic adversarial conditions. BOLA testing is a substantive component of demonstrating that API-layer authorization controls hold under adversarial pressure.
• ISO 27001 requires the effectiveness of access controls to be tested as part of an information security management program. BOLA represents a failure of access control at the API layer that standard access control reviews do not surface.
• NIS2 requires essential and important entities to manage security risks, including access control failures. APIs handling personal data, financial information, or operational systems that are vulnerable to BOLA represent a material risk within the scope of NIS2.

How to test for BOLA

Testing for BOLA requires a different approach from standard vulnerability scanning. The process involves:

• Creating controlled test objects with known ownership. Two or more test accounts are established with distinct data objects. Each account’s objects are known before testing begins, so that cross-ownership access can be verified definitively rather than inferred.
• Mapping object identifiers across the API surface. All endpoints that accept or return an object ID are cataloged, including endpoints that might expose identifiers indirectly in response bodies or headers.
• Attempting cross-ownership access. Using the credentials of one test account, requests are made to object identifiers belonging to the other. The test determines whether the API returns the data, rejects the request, or behaves inconsistently across different identifier formats or endpoint paths.
• Validating the finding. A positive result, where the API returns data belonging to another user, is confirmed through a second request that verifies the returned data is definitely not the requesting user’s. This is the exploit validation step that separates a confirmed BOLA finding from a false positive.
• Testing across the full object model. BOLA rarely affects only one endpoint. If an authorization check is missing on one resource type, it is frequently missing across related resource types that share the same underlying data model.

BOLA and continuous penetration testing

BOLA is particularly well-suited to continuous penetration testing because the authorization logic it tests changes every time new data models, endpoints, or user roles are introduced. An API that correctly implements object-level authorization at launch may introduce BOLA when new resource types are added without the same authorization checks being applied consistently.

In a continuous penetration testing model, BOLA is tested against the API as it changes rather than at a fixed point in time. New endpoints are discovered automatically, cross-ownership tests are run against the current data model, and confirmed findings surface to the security team with the exploitability evidence needed to act on them immediately.

This matters because BOLA does not generate signals that a monitoring tool detects. There are no anomalous error codes, no unusual traffic patterns, no signatures to match. The only way to know whether BOLA exists is to test for it deliberately. And in an environment where APIs change continuously, that testing needs to be continuous too.

Detecting BOLA with Equixly

Equixly tests for BOLA by reasoning about the API’s data model and authorization structure the way an attacker does, not by matching request patterns against signatures. It creates controlled test objects, attempts cross-ownership access across the full API surface, and confirms exploitability before surfacing any findings.

Since Equixly operates continuously, BOLA is tested every time material changes occur in the API. The false positive rate for BOLA findings is zero. Every finding represents a confirmed case of cross-ownership access, demonstrated with the specific request, identifier, and response that proves the vulnerability exists in the current environment.