Broken Object Level Authorization (BOLA) testing, proven
Broken Object Level Authorization (BOLA) (BOLA) — what it is, why a signature scanner structurally cannot find it, and how SuperPentest proves it with a controlled test, clean-session reproduction and hash-chained evidence mapped to API1 / A01: Broken Access Control.
BOLA is a vulnerability class a signature scanner structurally cannot find — here is what it is, why that is, and how SuperPentest proves it on your app.
What BOLA is
BOLA is IDOR’s API-native twin and the #1 risk in the OWASP API Security Top 10: an API endpoint accepts an object identifier and returns or modifies the object without confirming the caller owns it. Because APIs expose object IDs directly and are called programmatically, BOLA is both easy to exploit and easy to automate at scale.
What it looks like
A mobile app calls GET /api/v2/users/{id}/messages. Swap your own id for a colleague's and the API returns their private messages: it checked that you are logged in, never that you own that id. Scripted across a range of IDs it becomes a bulk breach.
Why a scanner misses it
This is a class a signature scanner structurally cannot reach. Signature scanning cannot evaluate ownership. Finding BOLA requires authenticating as two different principals, requesting each other’s objects, and comparing what the control identity is denied against what the test identity is wrongly granted.
How SuperPentest proves it
SuperPentest treats BOLA the way an attacker does, in four steps: it understands the business rule the feature is meant to enforce, runs a controlled test against it, then reproduces any candidate from a clean session — a fresh login with no leftover state — and finally records the impact with hash-chained request/response evidence mapped to the control it breaks. Nothing is reported as a finding until that clean-session reproduction succeeds; a candidate is not a finding.
- Understand — map the feature and the rule it should enforce.
- Controlled test — exercise the class safely, within the authorized scope.
- Clean-session reproduction — break in again from a fresh session to rule out flukes and stale state.
- Impact + evidence — hash-chained request/response, mapped to API1 / A01: Broken Access Control and your compliance controls.
Access-control testing by replay → · BOLA glossary →
Where it fits in coverage
Broken Object Level Authorization (BOLA) is one of the 35 vulnerability classes the engine tests every run, driven through 40+ specialist tools orchestrating 13 industry-standard open-source scanners. See the full coverage map or the 35 classes explained.
Related vulnerability classes
SQLi testing · XSS testing · IDOR testing · SSRF testing.
FAQ
Can a scanner find BOLA?
No — not reliably. Broken Object Level Authorization (BOLA) depends on context a signature scanner has no model of, so it is missed by construction. It takes an investigation that reproduces the issue to prove it.
How do I know a reported BOLA finding is real?
Every finding is reproduced from a clean session with hash-chained request/response evidence you can replay. If a run cannot complete the checks, it is stamped degraded coverage rather than passed as clean. See how findings are verified →
Test your app for BOLA. Book a demo or request an evaluation account. See the sample report.