Skip to content

Back to the catalog

BOLA in the Wild
labs.apisec.aiarticle

BOLA in the Wild

APIsec Research Labs analyzes 200 publicly disclosed HackerOne reports tagged IDOR/Improper Access Control (2021–2026) to build a six-family taxonomy of real-world BOLA vulnerabilities. Key finding: nearly half of confirmed BOLA cases involve unauthorized state-changing actions (delete, modify, approve, transfer, trigger) on another user's object rather than simple unauthorized reads, a class largely missed by test suites that only replay GET requests across accounts. The piece also argues IDOR and BOLA are distinct (IDOR is one route to a BOLA root cause) and warns that raw IDOR tag counts significantly overstate true BOLA prevalence.

TL;DR Analysis of 200 HackerOne BOLA disclosures shows ~half involve unauthorized state-changing actions, not just reads — a blind spot in typical BOLA testing.
Document

What it is

"BOLA in the Wild" (APIsec Research Labs, Bandana Kaur) — a qualitative analysis of 200 HackerOne reports tagged IDOR / Improper Access Control (Jan 2021–Jan 2026), filtered to confirmed BOLA cases and sorted into a six-family taxonomy. The summary covers the headline numbers; what follows is what changes an engineer's testing, not the framing.

What to do

Two concrete test gaps the piece names, both invisible to a standard IDOR sweep:

  • Test state-changing verbs cross-account, not just reads. The largest family, Action-Level Object BOLA, is an attacker performing delete / modify / approve / transfer / trigger on another user's object. A suite that replays GET across two accounts will, by construction, never see it. Replay POST/PUT/PATCH/DELETE and RPC-style triggers with Account B against Account A's object IDs.
  • **Test the chained-disclosure case: a legitimately obtained identifier presented where it should not be honored.** Here there is no guessable or enumerable reference — the ID is harvested from an earlier response, so it "looks clean." An IDOR-shaped search (looking for predictable/enumerable references) misses it entirely because nothing is being guessed. The reference is valid; the per-object authorization is still absent.

Why the numbers matter for prioritization

Don't size your access-control exposure by tag counts or a scanner's raw IDOR hits — the page says this overstates true BOLA signal "by a wide margin" and mis-targets remediation. The leading exclusion class was an outright wrong vuln type (XSS, SSRF, plain CVEs, subdomain takeover); also excluded were pure auth bypass with no object reference, business logic on the user's own resource, and reports too vague to classify. Remediate the root cause (missing per-object authz), not the identifier format.

Caveats

  • Deliberately qualitative: exact proportions are described as "still moving" though the distribution's shape is stable. For precise figures, sample sizes, and inter-coder agreement, the page directs you to the preprint and open dataset (linked at the end of the original, not in the fetched excerpt).
  • Method: an LLM was used only as a constrained schema-extraction assistant, never as the family-assignment decision maker; every case was human-reviewed. Re-coding disagreements clustered at the read-vs-action boundary and the user-vs-org crossing boundary.
  • The fetched text is truncated inside family #1, so five of the six families are not described here — consult the source for the full taxonomy.

Technologies named here

  • APIsec
  • Mozilla account/destroy endpoint
  • Nextcloud outOfOffice API
  • HackerOne
  • HackerOne bugs.json API
  • Cisco Secure Workload
  • Shopify staff/customer-records endpoint
  • Salesforce Aura API endpoint
  • Cosmos SDK
  • Nextcloud external storage configuration
  • Frontegg API key management
  • Autodesk
  • HackerOne GraphQL API
  • Meta/Instagram AI account-recovery assistant
  • ServiceNow Now Assist agents
  • Meta AI
  • GraphQL

Techniques named here