Broken Object Level Authorization in REST APIs
Most APIs skip the ownership check that prevents users from accessing each other's data.
Broken Object Level Authorization has sat at the top of the OWASP API Security Top 10 since the list first published in 2019, and the 2023 revision didn't move it. It's still there because the flaw is structural to how REST APIs work, and fixing it requires a discipline that most engineering organizations still don't apply consistently. It's because the flaw is structural to how REST APIs work, and fixing it requires a discipline that most engineering organizations still don't apply consistently. With API traffic making up 71% of all internet traffic in 2023, and a typical enterprise site logging an average of 1.5 billion API calls, a failure rate that would be a rounding error anywhere else becomes, at that volume, a near-certainty somewhere in the system.
What BOLA is, and what it is not
BOLA happens when an API correctly identifies who a user is but never checks whether that user is allowed to touch the specific object their request names. Authentication answers "who are you?" Authorization answers a different question entirely: are you allowed to touch this particular thing? A system can get the first answer completely right and still hand out somebody else's medical record, invoice, or vehicle control panel, because nothing downstream of login ever re-checks ownership.
This gets confused with IDOR (Insecure Direct Object Reference) constantly, and for good reason: the two describe overlapping territory. IDOR is the older term, and it focuses on the symptom, an internal reference like a database ID that's exposed and guessable. BOLA, which OWASP uses specifically for API contexts, shifts the focus to the broken logic behind that exposure. Every IDOR is a form of BOLA, but not every BOLA case involves an obviously predictable identifier; some involve identifiers that are not trivially sequential. The API framing matters because API responses are machine-readable by default, which makes automated, high-volume exploitation faster and the blast radius larger than a typical web form ever allowed.
BOLA is also frequently mixed up with its sibling, BFLA (Broken Function Level Authorization). The distinction is clean once you see it: in BOLA, the user has every right to be at that endpoint, but the failure lets them swap the object ID and reach someone else's data. In BFLA, the user shouldn't be allowed near the endpoint or function at all, regardless of whose object they're naming. One's a scoping failure on data. The other's a scoping failure on capability.
The mechanics of a BOLA attack, from probe to mass extraction
When the jargon is stripped away, the baseline attack is almost embarrassingly simple. If you change /api/users/1001 to /api/users/1002 in the address bar and hit enter, and the server doesn't check ownership, you're reading someone else's account. That's the entire technique in its rawest form, no tooling required beyond a browser.
Object identifiers appear everywhere in a real request, and each spot is its own exposed surface: URL path segments like /api/orders/5678, query strings such as ?user_id=1234, JSON fields buried in a request body like {"document_id": 101}, HTTP headers, and domain-specific identifiers like Vehicle Identification Numbers. Any one of these, left unchecked, is a door.
OWASP's own documentation lays out two scenarios that show how differently this plays out depending on what's behind the door. In the first, a car manufacturer's mobile app lets owners start or stop the engine and lock or unlock doors remotely, using the VIN as part of the request. If the API never confirms that the VIN in the request actually belongs to the account making it, an attacker can substitute any VIN and take remote control of a vehicle they've never owned or sat in. In the second, an e-commerce platform exposes shop revenue charts at a predictable path, something like /shops/{shopName}/revenue_data.json. A separate, seemingly harmless endpoint lists every shop name hosted on the platform. A short script can walk the entire list, pulling private revenue figures from thousands of merchants in one automated run. Neither scenario requires exotic tooling. Both require only that the developer forgot, or never knew, to check that the requester had a right to that specific object.
Bug bounty data on BOLA in the wild
An arXiv preprint from May 2026, "Broken Object Level Authorization in the Wild: An Empirical Taxonomy from 100+ Bug Bounty Disclosures," analyzed 200 HackerOne disclosures tagged either IDOR or Improper Access Control between January 2021 and January 2026. Of those, 138 fell under Improper Access Control and 62 under IDOR, spread across a severity range of 79 medium, 45 low, 42 high, 24 critical, and 10 unrated reports.
The most striking finding cuts against the way most teams still picture the vulnerability. Action-Level Object BOLA, meaning write, delete, or trigger operations performed across ownership boundaries, accounted for 41.7% of confirmed cases in the dataset. OWASP's own scenarios have historically leaned on identifier-substitution disclosure, essentially the "read someone else's data" story; the 2023 revision added one deletion example via a GraphQL scenario, but state-changing action isn't treated as a dominant category in the framework's guidance. The dataset suggests the industry's mental model is lagging the actual attacker behavior: this isn't primarily a story about reading, it's increasingly a story about attackers modifying or destroying records that were never theirs to touch.
The second finding is a visibility gap. Vertical BOLA, where a standard user escalates to admin-level access on an object, made up 11.9% of confirmed cases in the dataset. OWASP's 2023 attack scenarios focus on horizontal cases, meaning user-to-user, and the prevention guidance does not prominently address vertical-specific scenarios. That's a meaningful gap, because vertical escalation tends to carry disproportionately severe consequences relative to its share of documented cases.
Why BOLA keeps appearing despite being well-understood
None of this is a knowledge problem. BOLA has been documented, named, and ranked first on a widely read list since 2019. It persists because REST APIs are built to expose object identifiers in URLs and payloads, and that same transparency, the thing that makes APIs easy to build, document, and consume, hands attackers a clearly labeled target.
Development process compounds the structural issue. Teams routinely validate access once, at login, and then implicitly trust the session for everything that follows, treating "you're logged in" as a stand-in for "you're allowed to do this specific thing." Several popular frameworks make this worse by design: they'll happily generate an endpoint that accepts an object ID and does something with it, without any built-in authorization enforcement. The entire burden lands on an individual developer, at every single endpoint, every single time. In a CI/CD pipeline shipping new endpoints continuously, that per-endpoint check gets skipped, not out of ignorance but out of velocity. A microservices architecture where each service implements its own authorization logic, inconsistently or not at all, multiplies the gaps on its own.
Shadow APIs make enforcement structurally worse. Undocumented, unsupervised endpoints that security teams never see make up 4.7% of the average organization's active API inventory, and an API nobody knows exists is an API nobody's tested for BOLA. The average organization runs 613 APIs, and even a genuinely disciplined security team is facing a high-volume enforcement problem before anyone's made a single mistake.
Two breaches that show what BOLA costs in practice
Optus, Australia's second-largest telecom, suffered what's been described as Australia's largest data breach in history when, in September 2022, the personal information of close to 10 million people, nearly 40% of the country's entire population, was exposed. The data included 2.1 million government-issued IDs: passports, driver's licenses, Medicare numbers.
The root cause wasn't sophisticated. An API sat publicly exposed with no authentication requirement, the result of a 2018 coding error that broke access controls and simply stayed broken, undetected, on production systems for years. Customer IDs were sequential, 5567, 5568, and up from there, so an attacker could enumerate essentially the entire customer base by incrementing one number in one parameter. Within days of the breach becoming public, a ransom demand for AUD 1.5 million in Monero was made. Federal regulators opened action, customers filed suit, and Optus was forced into a mandatory security overhaul. None of the technique involved was novel. Sequential IDs and a missing auth check sit near the bottom of the sophistication scale for this category of bug, and the years-long gap between the error's introduction and its discovery says more about how invisible a forgotten endpoint can be than about any attacker's skill.
Spoutible, a social platform launched as a direct rival to X, suffered a breach in January 2024 that exposed sensitive personal information belonging to 207,000 users. Public reporting attributes the incident to API security vulnerabilities without detailing the specific technical mechanism, so the exact path shouldn't be assumed. What the incident does establish, regardless of mechanism, is that launching a platform years after BOLA was formally documented and ranked first on OWASP's list is no guarantee against it. Awareness of a category of bug and correct implementation of its defense are two separate achievements, and only one of them is visible in a breach notification.
The financial scale behind incidents like these isn't small. Imperva's Economic Impact of API and Bot Attacks report estimates that organizations lose a substantial sum annually, ranging into the hundreds of billions of dollars, to vulnerable or insecure APIs combined with automated bot abuse, a figure that accounts for a meaningful share of global cyber events and losses. BOLA-driven enumeration, the kind of scripted, sequential probing seen in the Optus and e-commerce examples above, sits as a primary driver of that automated abuse component.
Server-side authorization as the non-negotiable foundation
Every API endpoint that accepts an object ID and performs any action on it needs an object-level authorization check. Not most endpoints. Not the sensitive-looking ones. All of them, without exception and without a developer's case-by-case judgment call standing in for a policy.
That check has to run server-side, on every single request, full stop. A check enforced only in client-side code, hiding a button, graying out a menu item, isn't a security control at all; anyone with a proxy tool or a plain curl command bypasses it without effort, because the client is not a trust boundary.
What the check actually needs to confirm is narrower and stricter than "is this person authenticated." It needs to verify that the specific user, identified from a trusted source such as a signed JWT rather than a client-supplied field, has permission to perform this specific action on this specific object. OWASP flags an important limitation here: simply comparing the session's user ID against the ID parameter in the request catches only a narrow slice of real-world cases. It's a reasonable floor, not a finished defense, since plenty of legitimate access patterns (shared documents, delegated accounts, team resources) require authorization logic more nuanced than a straight equality check.
Identifier design and the limits of randomness as a control
OWASP's 2023 guidance recommends using random, unpredictable values, GUIDs, rather than sequential integers for record identifiers. It's sound advice, and it closes off the laziest version of the attack: nobody's incrementing to when the identifier is a long, random string.
But randomness solves exactly one problem, and here is precisely which one. It removes trivial enumeration and forces an attacker to obtain a valid identifier through some other channel before BOLA becomes exploitable. That's a real gain. It is not, however, the same as fixing the authorization gap. If an attacker holds a legitimate session of their own and gets hold of another user's GUID, through a shared link, a leaked log file, or another API response that happened to include it, the randomness of that identifier does nothing to stop them from using it. The GUID makes the ID harder to guess. It does not make the object harder to access once the ID is known, and only a genuine server-side authorization check does that.
Indirect reference maps offer one way to push further: instead of handing the client the real internal ID, the server issues a per-session token that maps back to the object on the backend, so the actual identifier never leaves the server. It's a real layer of defense, and organizations juggling sensitive object types often consider it worth the tradeoff. It also adds a genuine amount of implementation complexity, mapping tables, token lifecycle management, cache invalidation, and none of that complexity buys its way out of the fundamental requirement. The check has to be there. Everything else just makes the attacker's job harder before they ever get the chance to test for the check's existence.
