
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.
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
- Broken object-level authorization
- IDOR
- Action-Level Object BOLA
- Direct Object Reference family
- Tenant Isolation failure
- Workflow-Context BOLA
- Chained Disclosure
- Object Rebinding
- Vertical BOLA
- Horizontal BOLA
- GraphQL Global ID decode-increment-re-encode
- Prompt injection against AI agents
Related in AppSec
Flowise MCP Security Bypass Enables RCE
Inside an Oracle Database SQL Injection Attack | Huntress
OASIS
