BOLA has held the number one spot on the OWASP API Security Top 10 since the list existed. API1:2019, API1:2023, and every real-world API pentest report I've read this year keeps confirming why. It's the most impactful class of API vulnerability, and it's the one legacy scanners consistently fail to catch.
If your security tooling still relies on pattern matching against request payloads, you are almost certainly shipping BOLA into production. Let me walk through why the detection problem is hard, then show how autonomous pentesting companies handle it.
What BOLA Actually Is
Broken Object Level Authorization is a failure of per-request object ownership checks. An authenticated user makes a request against an API endpoint that operates on a specific object (typically referenced by an ID in the URL, body, or header), and the server executes the operation without verifying that the caller has rights to that specific object.
The authentication layer is fine. The user is who they say they are. The authorization layer is where it breaks. The server checks "is this user logged in" and skips "does this user own object 4471."
Here's the canonical vulnerable handler in Express:
app.get('/api/invoices/:id', authenticate, async (req, res) => {
const invoice = await db.invoices.findById(req.params.id);
if (!invoice) return res.status(404).send();
return res.json(invoice);
});
In this scenario, the invoice loads and is returned to whoever requests it. There is no check that invoice.tenantId === req.user.tenantId or invoice.userId === req.user.id.
Any authenticated user can enumerate /api/invoices/1, /api/invoices/2, /api/invoices/3 and read every invoice in the system.
Underestimated Impact
BOLA breaches don't look like breaches at the network layer. Every request is authenticated so your WAF and SIEM see a well-behaved user paginating through an API.
Meanwhile, the attacker is walking the entire object space. Optus in 2022 lost 9.8 million customer records through a BOLA on a customer-facing API. USPS Informed Visibility in 2018 exposed 60 million users through the same pattern. The USPS API returned all account data for any authenticated user's query, regardless of which account was queried. Both attacks looked like normal API traffic until they didn't.
The reason BOLA hits so hard is that the blast radius equals the object count. One missing check on GET /api/users/:id in a multi-tenant SaaS is a full customer database exfiltration.
Why Traditional Scanners Miss BOLA
Signature-based DAST tools scan an endpoint, fuzz its parameters, look for reflected patterns or error strings, and move on. That approach cannot detect BOLA, and the reason is architectural.
Detecting BOLA requires four things a signature scanner does not have:
Two authenticated identities in the same test run. You need User A and User B, each with a valid session, to prove that A can reach B's objects.
Object graph awareness. You need to know which IDs belong to User A so you can substitute an ID belonging to User B and compare responses.
Response equivalence checking. You need to compare A's response for A's object against A's response for B's object and confirm that the second call returned data that should have been forbidden.
Multi-format ID handling. Modern APIs mix numeric IDs, UUIDs, base64-encoded compound keys, GraphQL global IDs, and slug-based routes. The scanner has to enumerate all of them and know which ones actually resolve to objects.
Legacy scanners run as a single user against a single set of parameters. They physically cannot construct the test.
How Autonomous Pentesting Platforms Detect BOLA
Astra's platform is built as an agentic system that provisions multiple authenticated contexts, learns the application's object graph during a crawl phase, then executes cross-context authorization tests. Here's what actually happens under the hood.
Step 1: Multi-identity provisioning: The platform ingests credentials for at least two accounts, typically two low-privilege users in the same tenant plus one user in a separate tenant. Sessions are refreshed and rotated for the duration of the scan. This is table stakes for any BOLA test, and it's the step most tools skip.
Step 2: Object graph construction: During the authenticated crawl, the platform records every identifier it observes in every response. A response like this:
{
"invoice_id": "inv_4a7b91",
"customer": { "id": 5521, "email": "b@corp.io" },
"line_items": [{ "sku": "SKU-8823", "id": "li_9f2e11" }]
}
populates the graph with invoice_id=inv_4a7b91, customer.id=5521, and line_items[].id=li_9f2e11, each tagged with the user that observed them. IDs are typed (opaque string, numeric, UUID, base64) so subsequent enumeration uses format-appropriate mutation.
Step 3: Cross-context substitution: For every endpoint that accepts an object identifier, the platform executes the same request across identities. User A's session with User B's invoice_id. User B's session with User A's customer.id. Tenant A's user with Tenant B's line_items[].id. This is the actual BOLA test.
Step 4: Response equivalence and impact analysis: The platform compares the response User A gets for their own object against the response they get for User B's object. Three outcomes matter:
Identical structure with populated data: confirmed BOLA read.
200 with modified state: confirmed BOLA write (the platform verifies with a follow-up read from User B's session).
403 or 404: authorization is working.
The platform also probes for the common bypasses that make BOLA findings compound: HTTP method tampering (sending PUT where the auth check only fires on GET), header-based method override (X-HTTP-Method-Override: DELETE), ID format smuggling (submitting a UUID where the app expects a numeric ID and vice versa), and mass-assignment vectors that turn a BOLA read into a BOLA write.
Step 5: Business logic chaining. Astra's agent chains findings. If it detects that User A can read User B's invitation.id, it will attempt to PATCH that invitation's role field to escalate privilege, then use the escalated session to enumerate further. The output isn't a single BOLA line item. It's an exploit chain that starts at a public endpoint and ends at superadmin access, with the exact request sequence a human reviewer needs to reproduce it.
What the Output Actually Looks Like
A confirmed BOLA finding from the platform ships with the two-session request diff, the response comparison, the CWE mapping (CWE-639 for user-controlled key access), the OWASP API tag (API1:2023), the reachability proof, and the suggested code-level fix keyed to the framework the app is running.
If the app is Express, you get the middleware pattern. If it's Django REST Framework, you get the get_queryset override. If it's a GraphQL resolver, you get the field-level authorization directive. The fix ships in the language the developer is already writing.
The Takeaway
BOLA is the number one API vulnerability because it's structurally invisible to the tools most teams still rely on. Detecting it requires multi-user context, object graph awareness, and the willingness to chain findings into an actual exploit. Astra's autonomous pentesting platform is built around exactly that model, because in 2026 no other approach catches this class of bug at the rate it's being introduced.
Turn it on against a staging environment. If your API has BOLA, you'll know before your next release. If it doesn't, you'll have the proof your customers keep asking for.
