Finding the bugs scanners miss: BOLA, BFLA, and BOPLA

The single most common serious API bug is not injection or a missing patch. It is broken authorization: one user reaching another user's data, or a normal user calling a function meant for admins. It sits at the very top of the OWASP API Security Top 10 (API1: BOLA), and it is the class of bug that template and signature scanners are worst at, because there is nothing malformed in the request. A perfectly valid, well-formed request from the wrong identity is the vulnerability. This post is about the testing model that actually catches authorization bugs, and how Crossfyre runs it for you.

What are BOLA, BFLA, and BOPLA?

Three flavours of the same underlying flaw: the server trusts the caller more than it should.

• BOLA (broken object-level authorization). User A requests /api/orders/1043, an order that belongs to user B, and gets it. The classic "change the ID and see someone else's data." OWASP API1.
• BFLA (broken function-level authorization). A regular account calls an admin-only action, POST /api/admin/users or DELETE /api/users/99, and the server does it. The function exists; the check to gate it does not.
• BOPLA (broken object property-level authorization). A caller sets a property they should not control, {"role": "admin"} or {"is_verified": true}, and the API accepts it (mass assignment), or the response returns fields the caller should never see (excessive data exposure).

None of these have a payload a scanner can pattern-match. The request looks normal. What makes it a bug is who sent it and whether the server should have said no.

Why generic scanners miss all of this

A template scanner asks "does this response match a known-bad signature?" An injection fuzzer asks "does this malformed input break something?" Authorization has neither a signature nor malformed input. The only way to know that user A should not have been able to read order 1043 is to know who user A is, know the request should have been denied, and check whether it was. That requires identity and comparison, which most automated tools simply do not carry.

The model that works: replay as every identity, then diff

The reliable way to test authorization is a differential identity matrix. Take each endpoint you have discovered, and replay the same request as a set of known identities, then compare the responses:

• admin: the privileged baseline; what a legitimate high-privilege caller can do.
• user A: a normal user who owns some objects.
• user B: a different normal user, used to probe cross-tenant access to user A's objects.
• anonymous: no credentials at all, to catch endpoints that forgot to require auth.

When a lower-privileged identity gets data or an action it should not, you have a finding. User B reading user A's object is BOLA. A non-admin hitting an admin function is BFLA. Anonymous getting anything sensitive is broken authentication. It is conceptually simple and operationally fiddly, which is exactly the kind of thing worth automating.

Confirm before you report

Authorization findings are high-value, so a false positive is expensive: it burns your credibility with a client or a triager. Every authorization finding Crossfyre reports goes through a confirm-before-report step, re-issuing the request and checking the result reproduces, before it lands in your findings. What you get is the set of access-control gaps that actually held up, not a list of maybes to hand-verify.

How Crossfyre runs this for you

Authorization testing in Crossfyre runs as a mode inside a scan, fed by two things it already does: authenticated scanning (so it has real, logged-in sessions for each identity) and distributed recon and authenticated crawling (so it has the endpoints to test, no OpenAPI spec required). You supply the identities with role labels; it replays each discovered endpoint as each identity, diffs the responses, applies the privilege-aware and confirm-before-report checks, and streams the surviving findings to your dashboard.

• No spec needed. Endpoints come from recon and authenticated crawl, so you can test authorization on an API you do not have documentation for.
• Wired to recon. Authorization testing is one stage of a pipeline that already mapped the surface, not a separate tool you point by hand.
• A paid-tier capability. Authorization testing (and authenticated scanning) unlock on Pro and are enforced server-side.

For the full breakdown of BOLA/BFLA/BOPLA and how the identity matrix works, see API authorization testing. For how the logins that feed it are handled, see authenticated scanning.