How to detect broken object level authorization (BOLA) in APIs

Detecting BOLA is fundamentally different from testing for injection or input validation issues. A successful attack produces a normal 200 OK response with valid data, making it invisible to traditional scanning approaches. Effective detection requires testing from multiple user perspectives and verifying whether access control is enforced at the object level.

The sections that follow provide a complete, practitioner-focused methodology for identifying BOLA vulnerabilities, from manual testing workflows and authorization matrix design to API-specific edge cases and automated proof-based detection.

Broken object level authorization (BOLA) is an API security vulnerability where an application fails to verify whether an authenticated user is allowed to access a specific object, such as a user record, order, or document. This allows attackers to access or manipulate data that belongs to other users by changing object identifiers in API requests.

Why BOLA is hard to find

BOLA consistently ranks as the number one OWASP API Security Top 10 risk because it is easy to exploit and remarkably easy to miss. The Spoutible social platform authenticated every request correctly – and still exposed user data including password hashes because it never checked whether the requesting user owned the specific data being returned. Attackers simply incremented user IDs. A widely reported Grafana vulnerability followed the same pattern, allowing cross-organization access through manipulated identifiers (from authenticated users in a different organization).

What makes BOLA difficult to detect is that it does not behave like other vulnerabilities. Every request is authenticated. Every response is valid. There are no errors, no payloads, and no obvious anomalies. From the API’s perspective, everything appears to be working correctly.

BOLA only becomes visible when you test from the perspective of a different user. Detection depends entirely on context – specifically, whether the data returned belongs to someone else.

This guide covers the full methodology for detecting BOLA in practice, including manual testing workflows, authorization matrix construction, API-specific nuances, and how automated proof-based scanning validates real findings at scale.

Detecting broken object level authorization (BOLA)

Detecting BOLA requires testing whether an authenticated user can access objects that belong to another user by manipulating object identifiers in API requests. Because successful exploitation returns a normal 200 OK response with valid data, there is no signature to detect. Effective detection requires explicit cross-user testing with multiple authenticated sessions and a clear understanding of ownership boundaries.

Why standard scanning misses BOLA

Most vulnerability scanners look for abnormal behavior – malformed responses, error messages, or execution of injected payloads. BOLA produces none of these signals:

• Requests are valid and authenticated
• Endpoints are legitimate
• Responses are well-formed
• Status codes are normal

The only difference is who receives the data. This creates three structural challenges for testing:

• No negative signal – success looks normal
• Context dependency – ownership is not visible in the response
• Coverage complexity – every identifier-based endpoint must be tested across roles

Without multi-session context, automated tools cannot distinguish between legitimate and unauthorized access.

Setting up for BOLA testing: Prerequisites

Test account requirements

BOLA testing requires multiple real user accounts with distinct data ownership, ideally three or four:

These must be real application accounts with actual data. Fabricated or nonexistent identifiers can produce misleading 404 responses and hide authorization flaws.

API endpoint inventory

Identify all endpoints that accept object identifiers, for instance:

• Path parameters – /orders/{id}
• Query parameters – ?userId=123
• Request body fields – { "accountId": "abc" }
• GraphQL arguments – user(id: "...")

Where possible, derive this inventory from OpenAPI specifications. In their absence, build coverage from captured traffic or automated discovery using various API discovery methods. Mature teams continuously update this inventory as APIs evolve rather than treating it as a one-time exercise.

Proxy and tooling setup

Use an intercepting proxy such as Burp Suite or OWASP ZAP:

• Capture requests from User A
• Extract identifiers
• Replay requests using User B

Tools like Burp Autorize can automate cross-session replay and highlight differences between responses. These tools compare responses across sessions and can optionally include unauthenticated comparisons, but coverage still depends on the traffic you capture.

The manual BOLA detection methodology

Step 1: Map every object-identifier endpoint

Document every endpoint that accepts identifiers, including parameter location and data type. This defines your test scope. In mature environments, this mapping is generated from OpenAPI specifications and maintained automatically as APIs change.

Step 2: Authenticate as user A and enumerate identifiers

Interact with the application as User A and collect identifiers returned in API responses:

• User IDs, order IDs, document IDs
• Identifiers embedded in nested objects
• Tokens reused across workflows

Trace how identifiers flow between endpoints. Many APIs pass identifiers from one response into subsequent requests, creating chains that must be tested end to end.

Step 3: Authenticate as user B and substitute identifiers

Replay requests using User B’s session:

GET /api/orders/USER_A_ORDER_ID
Authorization: Bearer USER_B_TOKEN

Evaluate responses carefully, since BOLA does not always present as a clear success or failure:

• 200 OK with full object data – confirmed BOLA
• 200 OK with partial data – potential field-level authorization gap
• 200 OK with empty or null data – possible silent authorization failure pattern
• 403 or 404 – authorization enforced

A 200 OK with empty or null data does not always indicate correct behavior. Some APIs suppress unauthorized results instead of returning an error. If the same request returns populated data for the owning user but empty data for another user, this may indicate inconsistent authorization logic rather than proper enforcement.

The key is comparison across sessions. Always validate how the same request behaves for different users and follow up with write operations to confirm whether access control is consistently enforced.

Step 4: Test all HTTP methods and stateful workflows

BOLA is not limited to read operations. Test write and destructive actions:

DELETE /api/documents/USER_A_DOCUMENT_ID
Authorization: Bearer USER_B_TOKEN

Also test multi-step workflows:

• Create → update → delete sequences
• State-dependent operations
• Endpoints requiring prior actions or tokens

Many BOLA issues only appear in stateful workflows where authorization checks are inconsistent across steps.

Step 5: Test vertical BOLA scenarios

Use lower-privilege accounts to access higher-privilege objects:

GET /api/admin/settings/ADMIN_ID
Authorization: Bearer USER_B_TOKEN

Vertical BOLA is a form of vertical privilege escalation, where a lower-privilege user accesses resources belonging to a higher-privilege role. These issues often carry higher impact because they cross both ownership and privilege boundaries.

Step 6: Test identifier variants and edge cases

Test beyond simple ID substitution:

• UUIDs (also referred to as GUIDs in some systems)
• Slugs and human-readable identifiers
• Reference tokens and indirect identifiers

Also consider:

• Pagination and bulk endpoints
• Rate limiting and enumeration constraints
• Partial responses across large datasets

Security controls that obscure identifiers do not eliminate BOLA – they only make exploitation less obvious.

Building an authorization matrix for systematic coverage

Ad hoc testing does not scale and is not consistent. An authorization matrix defines expected behavior across endpoints and user roles, showing at a glance who should be able to access what – and who should not. By mapping API operations against roles and expected responses, it turns implicit access control assumptions into an explicit, testable model that can be applied consistently across the entire API surface.

Here’s a basic authorization matrix:

This matrix serves two purposes:

• Documentation of intended authorization behavior
• A structured test specification

Each cell where access should be denied becomes a test case.

Building the matrix from an OpenAPI specification

In reality, the matrix isn’t created manually (which would be impractical anyway). Start from your OpenAPI or Swagger definition:

• Identify all endpoints with object identifiers ({id}, userId, accountId)
• Extract HTTP methods and parameter locations
• Map each endpoint to expected role behavior (owner, non-owner, admin, scoped roles)

For example:

paths:
 /orders/{orderId}:
   get:
     parameters:
       - name: orderId
         in: path

This becomes a row in your matrix. You then define expected responses per role, turning API design into an explicit authorization model.

From matrix to test cases

Each matrix cell translates directly into a test:

• User B + GET /orders/{id} → expected 403
• User B + DELETE /orders/{id} → expected 403

This creates a complete and repeatable set of BOLA test cases across all endpoints and roles.

Operationalizing the matrix

Mature AppSec teams use the matrix as a living artifact:

• Generate automated tests from the matrix
• Run them in CI/CD pipelines on every deployment
• Validate that authorization behavior does not regress over time

This ensures that new endpoints and code changes do not introduce silent authorization gaps.

Why the matrix-based approach matters

The authorization matrix provides three key advantages:

• Complete coverage: Every endpoint-role combination is tested, not just those a tester happens to explore
• Repeatability: The same tests can be run continuously, not just during manual assessments
• Policy clarity: Undefined or ambiguous cells expose gaps in authorization design before they become vulnerabilities

This is the difference between ad hoc testing and a repeatable AppSec control. Instead of relying on manual exploration, teams can systematically validate that object-level authorization behaves as intended across the entire API surface.

BOLA detection in GraphQL and non-REST APIs

BOLA in GraphQL APIs

GraphQL API testing introduces additional complexity because authorization is often implemented at the resolver or field level rather than at the endpoint level:

query {
  user(id: "USER_A_ID") {
    email
    paymentMethods {
      cardNumber
    }
  }
}

Key risks include:

• Resolver-level gaps where nested objects bypass authorization checks
• Field-level exposure where sensitive attributes are returned even if the object is restricted
• Mutation vulnerabilities that allow unauthorized updates or deletions

A query may correctly restrict access to the top-level object but still expose nested fields without validation. Effective testing requires validating each layer independently.

Use introspection to enumerate all queryable types and arguments, then systematically test cross-user access for both queries and mutations.

BOLA in WebSocket APIs

WebSocket APIs operate through persistent connections and message payloads rather than discrete HTTP requests. Detection requires:

• Capturing identifiers from User A’s session
• Replaying messages with User B’s session
• Observing whether unauthorized data is returned

Because connections are stateful, inconsistencies in authorization can occur across message sequences rather than individual requests.

BOLA in microservices

In microservices architectures, authorization is often assumed rather than enforced. One service validates access, and downstream services trust that validation without re-checking ownership.

This creates gaps where internal services process requests without verifying authorization boundaries. Testing for this requires:

• Identifying internal service endpoints where possible
• Observing service-to-service communication patterns
• Verifying that authorization is enforced at each layer, not just at the entry point

These issues are common in distributed systems and can persist unnoticed without targeted testing.

Automated BOLA detection: What tools do well and what they miss

What signature-based scanners cannot do

Traditional scanners detect anomalies – but BOLA produces none. Without multi-session context, they cannot identify cross-user access.

Semi-automated tools

Tools like Burp Autorize replay requests using a second session and compare responses across users. They can optionally compare against unauthenticated responses to highlight differences. These tools are effective but limited:

• Coverage depends on captured traffic
• Manual interaction is required
• Systematic endpoint coverage is difficult

Invicti’s proof-based BOLA detection

Invicti’s API DAST scanner performs automated multi-session testing:

• Authenticates with multiple user accounts
• Substitutes object identifiers across sessions
• Confirms unauthorized access with real responses

The key difference is validation. Instead of flagging every identifier-based endpoint as a “potential BOLA” risk, the scanner confirms which vulnerabilities are actually exploitable through cross-user testing.

This distinction is critical in practice. Pattern-based approaches generate large volumes of theoretical findings, while proof-based detection focuses on confirmed authorization failures that developers can immediately reproduce and fix. By reducing false positives, it aligns with a DAST-first approach that prioritizes validated risk over theoretical findings.

Real-world BOLA incidents that define the detection standard

• A Grafana vulnerability (CVE-2024-1313) allowed an authenticated user in one organization to delete dashboards belonging to a different organization by issuing a DELETE request to /api/dashboards/uid/{uid} with a valid dashboard UID. The API verified that the user was authenticated but failed to enforce organization-level ownership checks and treated cross-organization deletion requests as authorized without verifying ownership. This is a classic cross-tenant BOLA scenario where authentication is correct but object-level authorization is missing. A simple test using two accounts from different organizations and replaying the delete request with the same dashboard UID would have exposed the issue. 
• The Spoutible breach exposed user records, including password hashes, through sequential user ID enumeration. Attackers incremented identifiers and retrieved data belonging to other users. This vulnerability could have been detected using the core BOLA methodology – capturing identifiers from one account and replaying requests from another to confirm cross-user access.
• Automotive API research has shown that substituting VINs (vehicle identification numbers) in API requests can expose owner data such as names, email addresses, and other PII. Even though VINs are externally visible identifiers, the API must still enforce ownership checks. This illustrates that identifier visibility does not reduce BOLA risk – only proper authorization does.
• Public reporting on fintech API breaches has described incidents exposing millions of financial records due to missing object-level authorization checks. These vulnerabilities often originate in initial API design and persist unnoticed in production. Systematic cross-user testing across account identifiers would reveal these issues early, before large-scale exposure occurs.

Distinguishing true BOLA from false positives

Not all cross-user access indicates a vulnerability. Common false positives include:

• Public resources: Endpoints intentionally designed to return the same data to all users can appear vulnerable but actually reflect expected behavior.
• Admin visibility: Administrative roles may legitimately access cross-user data in multi-tenant systems.
• Aggregated endpoints: Summary data may include multiple users without exposing individual ownership.
• Shared objects: Collaborative platforms often allow controlled cross-user access.

A true BOLA exists only when access violates the intended ownership model. The key confirmation test is whether the application’s data model defines the resource as private to a user and that restriction fails in practice.

Find and confirm BOLA before the attackers – and do it at scale

Manual testing can uncover BOLA vulnerabilities, but it does not scale across modern API environments with hundreds of endpoints and continuous deployment cycles.

Invicti’s proof-based BOLA detection automates multi-session testing, confirms exploitability with real request and response evidence, and integrates directly into development workflows. This allows teams to focus on fixing vulnerabilities that attackers can actually use rather than chasing theoretical risks.

Get a demo to see how automated BOLA detection works in practice on the Invicti Platform.