Broken Object Level Authorization (BOLA): Impact, and Prevention

Broken object level authorization (BOLA) is an API flaw where a server returns or modifies an object based on an identifier supplied by the client, without confirming that the caller owns that object. A customer requests their own invoice, changes one digit in the URL, and receives somebody else's.

Prevalence turns that simplicity into a problem. A 2026 analysis of publicly disclosed bug bounty reports classified 107 submissions in detail and confirmed 78.5% of them as genuine BOLA, giving the vulnerability class its first large-scale empirical measurement.

What is Broken Object Level Authorization (BOLA)?

BOLA holds the top position in the OWASP API Security Top 10 as API1:2023, and the ranking reflects how ordinary the mistake is. An endpoint accepts an object identifier, fetches the matching record, and returns it, having established who the caller is without establishing what that caller owns.

Endpoint access is not the failure point. OWASP notes that reaching the endpoint is intended behavior, and the violation happens at the object level through manipulation of the ID.

Authentication and authorization separate here. Authentication answers who is calling, authorization answers what that caller reaches, and BOLA describes systems that answer the first question correctly and skip the second entirely.

How Attackers Exploit BOLA Vulnerability?

A BOLA exploit runs in five steps, none of which requires specialist tooling:

1. Authenticate normally. The attacker registers a legitimate account and obtains a valid session token, so every request that follows carries genuine credentials.
2. Observe an object reference. Browsing the application surfaces identifiers in URLs, request bodies, or headers, such as a call to /api/v1/invoices/1043.
3. Tamper with the identifier. Changing 1043 to 1044 produces a request that stays syntactically valid while pointing at a different customer's record.
4. Receive the object. A vulnerable server matches the record, confirms the token is valid, and returns the invoice without asking whether the caller owns it.
5. Enumerate at scale. A short script iterates through the identifier range and extracts every object the endpoint serves.

Why BOLA Ranks First in the OWASP API Security Top 10

Three properties keep BOLA at the top of the list. Exploitation needs no privilege escalation, no malware, and no malformed traffic, since each request carries valid credentials and correct syntax.

Detection failure compounds the exposure. Server logs record authenticated requests returning successful responses, which reads as ordinary use until somebody compares how many distinct objects a single session touched.

Scale completes the picture. One unchecked identifier exposes every object behind that endpoint, converting a single logic error into disclosure of an entire table.

Why BOLA is Not Only About Reading Data

Most explanations stop at data exposure, which understates the risk considerably. In the 2026 bug bounty analysis, action-level cases, where an attacker performs state-changing operations on objects belonging to somebody else, accounted for 41.7% of confirmed BOLA findings.

Modification, cancellation, and transfer sit inside that share. An attacker who reaches another customer's order object frequently updates or deletes it rather than merely reading its contents.

Object rebinding forms a subtler variant still. Applications that accept an ownership field from the client, such as a user ID inside a request body, let an attacker reassign an object to themselves, and the pattern resists neat classification in existing vulnerability taxonomies.

BOLA vs IDOR vs BFLA

These three terms circulate around the same territory, and precision matters when writing a finding:

IDOR and BOLA describe one defect from different angles. IDOR, the older web term, emphasizes the exposed reference, while BOLA names the missing authorization check and extends to request bodies, headers, nested object graphs, and inconsistencies across microservice boundaries. BFLA differs in direction: BOLA yields data belonging to peers, whereas BFLA yields capabilities belonging to administrators.

Real-World BOLA Breaches

These two telecom incidents show what an unchecked object reference produces at national scale.

Optus (2022). An endpoint shaped as /users/{userId} sat on a secondary subdomain, reachable without authentication and serving sequential customer identifiers. Attackers incremented through the range and extracted records covering roughly 10 million customers, close to 40% of Australia's population. An access-control fix from 2018 had reached the main site by 2021 and never reached the forgotten domain.

T-Mobile (2023). An exposed API returned account data including names, billing addresses, phone numbers, dates of birth, and account numbers. Extraction ran from 25 November 2022 until detection on 5 January 2023, affecting 37 million accounts across six undetected weeks. An FCC settlement in September 2024 imposed a $31.5 million penalty covering this and earlier incidents.

Forgotten infrastructure links both cases. Neither breach required a novel technique, and both ran through endpoints the organization had stopped actively tracking.

How AI Agents Change the BOLA Equation

Autonomous agents alter the economics of exploitation. An attacker abusing a compromised agent, or exploiting the excessive agency that OWASP names among its top risks for LLM applications, iterates through object identifiers at machine speed instead of scripting a patient crawl.

Code generation compounds the exposure from the opposite direction. Applications assembled by AI coding assistants frequently ship the exact flaw described here, accepting a user identifier from the URL without checking it against the authenticated session.

Delegation chains introduce a failure mode of their own. Where one agent hands a task to another and each hop issues fresh credentials, downstream calls execute with permissions the original user never granted, breaking object-level authorization at the identity layer rather than inside a single endpoint.

Baselines blur as a result. A legitimate agent touches far more objects than any human user, so the enumeration signal that once flagged a suspicious session grows harder to separate from ordinary automated work.

Why Automated Scanners Miss BOLA

Scanners detect patterns, and BOLA leaves none behind. A request for invoice 1044 is structurally identical to a request for invoice 1043, so separating the two demands knowledge of which customer owns which record.

Data models live outside the scanner's view. Ownership relationships exist in application logic and database relations that a dynamic scan never sees, which explains why BOLA survives code review, CI pipelines, and automated testing that catches injection flaws reliably.

Behavioral analysis offers the workable alternative. Sessions requesting far more distinct object identifiers than a normal user produce the enumeration signal worth alerting on.

How to Prevent BOLA

Prevention rests on one principle: the server decides ownership on every object access, and the client never influences that decision.

• Enforce authorization in a centralized layer. Per-endpoint checks scattered through a codebase drift over time, and one missed handler reopens the flaw.
• Deny by default. Object access fails closed unless an explicit rule permits the current principal to reach it.
• Derive ownership server-side. Ownership comes from the session and a trusted data store, never from a field the client supplies.
• Reject session-ID comparison as a complete fix. OWASP states plainly that matching the token's user ID against the ID parameter addresses only a narrow subset of cases.
• Treat unpredictable identifiers as defense in depth. UUIDs slow enumeration and authorize nothing on their own.
• Return 404 rather than 403 on failed authorization. A 403 confirms the object exists, handing an attacker a working enumeration oracle.
• Log object access with the requesting principal. Enumeration becomes visible only when logs record which identity touched which object.

How to Test for BOLA

Testing depends on context that automation lacks, so the technique centers on comparison between accounts:

• Create two accounts in the same tenant. Capture an object identifier as the first user, then request it while authenticated as the second.
• Repeat across every verb. Read access frequently fails closed while PUT, PATCH, and DELETE on the same object stay open.
• Test nested and related objects. Endpoints such as /users/{id}/documents/{docId} require an ownership check on both identifiers.
• Cross-tenant boundaries. Multi-tenant platforms often isolate tenants at the routing layer and skip verification at the object layer.
• Inspect request bodies and headers. Identifiers carried outside the URL attract less scrutiny during review.
• Cover every consumer of the API. Mobile clients routinely call endpoints the web application never exposes, and mobile app scanning surfaces those hidden calls along with the credentials embedded beside them.

Finding the APIs Before Testing Them

Authorization testing depends on inventory. Optus lost customer records through an endpoint on a subdomain that had slipped out of active tracking, and no amount of testing reaches an API nobody remembers owning.

CloudSEK's BeVigil maps the external API attack surface, covering undocumented endpoints, forgotten subdomains, and the API calls embedded inside published mobile applications.

Surface mapping and authorization testing solve different halves of one problem. BeVigil establishes which endpoints exist and face the internet, while verifying that each one checks object ownership stays a job for authenticated testing against the application's own data model. Agent and model-serving endpoints sit in a separate category, AI attack surface monitoring, which CloudSEK covers through AIVigil rather than BeVigil.

Frequently Asked Questions

Is BOLA the same as broken access control?

No, BOLA is one specific type of broken access control. Broken access control names the wider category in the OWASP Top 10 for web applications, while BOLA names the object-level failure inside APIs.

Which CWE maps to BOLA?

BOLA maps most closely to CWE-639, authorization bypass through a user-controlled key. Related entries include CWE-284 for improper access control and CWE-863 for incorrect authorization.

Can BOLA affect GraphQL APIs?

Yes, BOLA can affect GraphQL as readily as REST, since queries reference objects by identifier in the same way. Nested queries widen the exposure by reaching related objects in a single request.

Does rate limiting prevent BOLA?

No, rate limiting slows enumeration without closing the authorization gap. An attacker pulling records slowly still reaches every object the endpoint exposes.

Do web application firewalls block BOLA?

Web application firewalls rarely block BOLA, because the malicious request carries valid credentials and correct syntax. Behavioral rules that flag unusual object enumeration provide partial coverage.

How severe is a typical BOLA vulnerability?

Severity commonly lands in the high to critical range, driven by the volume of records one flaw exposes. Bug bounty programs frequently pay top-tier rewards for BOLA submissions.