What 100+ BOLA Reports Taught Us About Where Object-Level Authorization Actually Fails

Your API has a bouncer. Very professional. Checks every ID at the door. Unfortunately, once you're inside, you can walk into the kitchen, rearrange everything, and delete someone else's reservation and he's still at the front door, extremely proud of himself.

Most security teams know what BOLA is. Broken Object Level Authorization, the vulnerability where an API doesn't verify that you're allowed to access the specific object you're referencing, not just the endpoint. It has sat at the top of the OWASP API Security Top 10 since 2019. There are guides, courses, and CTF challenges built around it.

And yet we analyzed over 100 validated, publicly disclosed bug bounty reports from HackerOne spanning 2021 to 2026, across 29 organizations including GitHub, GitLab, Shopify, Mozilla, and more, and found something that should give every security team pause.

The way most teams are testing for BOLA doesn't match how BOLA actually shows up in the wild. Here's what the data says.

First, a Quick Note on the Tag Noise

One number worth flagging: roughly 39% of reports tagged IDOR or Improper Access Control on HackerOne don't describe BOLA under rigorous criteria. Wrong vulnerability class entirely, auth bypass without object reference, business logic on a user's own resources. If your team is using platform tag-counts to estimate BOLA exposure, you're likely overstating the signal significantly. Hence, these were excluded under the prefilter criteria of our research.

Finally, the 84 confirmed, in-scope reports are what everything below is drawn from. The full dataset, classification methodology, and analysis scripts are available on GitHub.

Six Types of BOLA. Two Dominate.

We classified every confirmed report based on why the authorization check failed, not the endpoint semantics or HTTP method, but the primary structural reason the check was absent or stale. This produced six families.

Action-Level Object and Direct Object Reference together account for 78.6% of all confirmed cases. Here's what each family looks like in practice

Direct Object Reference BOLA (36.9%) is the classic. The attacker substitutes an object identifier: sequential integer, UUID, username, encoded ID, and accesses another user's object in a single request. No prior acquisition step. A confirmed example: GET /ocs/v2.php/apps/dav/api/v1/outOfOffice/{userId} on Nextcloud. Substitute any other user's username and you get their private out-of-office data, including travel destination and phone number. The server confirmed the requester was authenticated. It never asked whose data it was returning.

This pattern appeared in 2023–2026 disclosures from HackerOne, GitHub, DoD systems, and Shopify. Decades of developer education on this specific vulnerability, and it's still the second-largest confirmed family. Awareness clearly isn't the bottleneck. Enforcement is.

Action-Level Object BOLA (41.7%) is where the testing gap actually lives, and we'll come back to this in detail below. The attacker performs an unauthorized state-changing action on another user's object: delete, modify, approve, transfer, trigger. Not read. Act.

The four remaining families: Tenant Isolation, Workflow-Context, Chained Disclosure, Object Rebinding split the remaining 21.4% and tend toward greater exploit complexity. They're covered in full in the paper. The two that matter most for immediate test protocol changes are the ones above.

The Finding That Should Change Your Test Scope

Most BOLA guidance, OWASP included, usually frames this as a data exposure problem. The implicit assumption is GET. You access something you shouldn't be able to see. Standard test suites are built around that model: can Account B read Account A's data?

Here's the number that breaks that assumption:

State-changing operations like modify, delete, trigger, account for 46.4% of confirmed cases.

Read operations are still the single most common action type at 52.4%. But nearly half of confirmed real-world BOLA involves an attacker doing something to another user's object, not just looking at it.

The deletion cases (15.5%) deserve specific attention. They're high-impact, often irreversible, and unlikely to trigger data-exfiltration monitoring because nothing is being exfiltrated. It's being gone. Confirmed deletion cases in this dataset include API tokens (Mozilla), analytics reports (HackerOne), external storage configurations (Nextcloud), and full user accounts. In a documented case in Mozilla, an attacker sends victim's email in a POST to /v1/account/destroy using their own valid session; server doesn't verify the session-email binding. A compromised-data alert won't fire when the data is gone.

The implication for testing is direct: a test suite that only validates GET-method cross-user access fails to detect the largest confirmed family in this dataset. Action-Level Object BOLA at 41.7% is entirely invisible to a read-only test protocol.

1 in 9 Cases Are Vertical

85.7% of BOLA failures in this dataset are horizontal, a standard user accessing a peer's objects. That's the case every developer guide and OWASP example describes. 11.9% are vertical: a standard user accessing or modifying objects owned by an administrator.

In every vertical case in this dataset, the attacker's role legitimately allowed them to call the endpoint. The missing control was ownership of the specific object, not access to the function. This is not a role-gating failure; it's an ownership check that was never implemented for higher-privileged objects.

Confirmed examples include a standard Nextcloud user deleting an admin's external storage configuration (#2212627) and a Frontegg admin modifying an Owner's API key via an undocumented PATCH method (#2149124). The attacker gains effective administrative reach without ever being granted an administrative role.

Vertical BOLA doesn't appear in most test plans. It's present in 1 in 9 confirmed real-world cases.

What This Means for You

Standard BOLA testing covers one configuration: two accounts, GET request, active objects, peer-level ownership. That's one cell of a larger grid.

For developers:

The single most protective change you can make is architectural: derive object ownership from the authenticated session server-side on every request. Never read ownership from the request body or query parameter. If your authorization logic trusts owner_id from the client, you're one field modification away from Object Rebinding BOLA.

Beyond that:

• Apply ownership scoping at the database query layer, not in application code after retrieval
• Re-evaluate authorization when object state changes. Deactivation and removal must invalidate object-level access grants, not just session validity
• Do not treat identifier opacity (UUIDs, encoded IDs) as a substitute for access control

For testers and AppSec engineers:

Your current test suite has a measurable gap if it only validates GET-method cross-user access. A complete BOLA test matrix needs:

• All mutating operations (DELETE, PATCH, POST-to-trigger) across ownership boundaries
• Two accounts with genuinely distinct object ownership, single-account testing can't confirm a cross-user failure
• Objects in all lifecycle states: active, archived, deactivated, deleted
• Tenant-boundary testing for multi-tenant SaaS: two separate organizations, verified isolation
• Vertical scope: test whether a lower-privileged session can act on objects owned by higher-privileged roles

The Number to Sit With

Across the 2023–2026 window of this dataset, which spans the full OWASP API Security Top 10 2023 update, there is no meaningful decline in BOLA prevalence. The problem was never that teams didn't know BOLA existed. It's that the version they were testing for was always smaller than the one shipping to production. The gap between awareness and remediation is where the real work is.

Want to See If Your APIs Hold Up?

BOLA has been on every security team's radar for years. What this data makes clear is that knowing about a vulnerability class and actually testing for it are two different things. The version of BOLA most teams are defending against is real, but it's only half the picture. State-changing operations, vertical privilege boundaries, archived object states, chained identifiers: these aren't edge cases. They're confirmed, disclosed, rewarded vulnerabilities from organizations with mature security programs. Standard test protocols were built around a narrower threat model than what's actually being exploited, and that mismatch is what this dataset reflects. Closing this gap requires expanding the test matrix to match how BOLA actually behaves in production environments. This research from APIsec Research Labs is a starting point for doing exactly that.

If the patterns in this research look familiar, it's worth asking whether your current test coverage would have caught them. APIsec's platform automatically generates and runs BOLA test scenarios across a range of object-level authorization failure modes. If your APIs are handling sensitive objects or user data, it's worth finding out where the gaps are before someone else does. See it in action