Skip to content
All posts

Why most automated scanners miss BOLA in production APIs

2 min readbola · owasp api top 10 · api security · research

Broken Object Level Authorization (BOLA) sits at the top of the OWASP API Security Top 10 not because it is exotic, but because it is universal. Any REST API that takes an object ID in the path - which is to say, most REST APIs - is one missing authorization check away from leaking customer data.

We looked at a sample of automated scanners that claim "OWASP API Top 10 coverage" and most of them treat BOLA as a checkbox you tick by running a generic web fuzzer against the API. That misses the actual exploit.

Why a fuzzer cannot catch BOLA

A BOLA exploit is structurally:

  1. User A is authenticated.
  2. User A requests GET /orders/{id} where {id} belongs to User B.
  3. Server returns User B's order.

A generic web fuzzer has User A's token. It does not have User B's {id}. It does not have User B's token to confirm the leak is a real BOLA hit and not a 200 OK with empty data. Without all three (two tokens + the cross-account ID), the scan returns "no findings" and the customer believes their API is BOLA-clean.

What we actually need

A BOLA scanner needs:

NANOTESTING's apiauthz scanner takes the spec, the two tokens (encrypted in auth_credentials with ENCRYPTION_KEY), and walks every spec operation that takes an object ID. The output is a per-endpoint finding with the exact request signature, the response status, and the OWASP API ID.

The honest part

This requires the customer to upload an OpenAPI spec AND to put two tokens in target credentials. Without both, we cannot probe BOLA - we skip the step and say so in the report ("no auth secret configured; BOLA probe needs a logged-in token"). The alternative - claiming OWASP API Top 10 coverage from a single-token fuzzer - is the silent miss that costs customers their data.

If you have an OpenAPI spec, drop it on the dashboard and run the scan.