BOLA vs BFLA: the API authorization flaws scanners miss

Look at almost any serious API breach of the last few years and you will find the same root cause: not a clever injection payload, but a missing authorization check. Someone requested an object that was not theirs, or called a function they should never have reached, and the server handed it over. These are the two classes at the top of the OWASP API Security Top 10, BOLA at number one and BFLA at number five, and together they account for the majority of real-world API compromise.

They are also the flaws your scanner will never report. Understanding why starts with knowing exactly what each one is.

What is BOLA (Broken Object Level Authorization)?

BOLA is a failure to check that the user asking for an object is allowed to have that specific object. APIs expose objects by identifier, /orders/124, /users/89/profile, /documents/abc-123, and the vulnerability is simple: the endpoint authenticates you (it knows you are a logged-in user) but never verifies that order 124 belongs to you before returning it.

So an attacker logs in with their own account, sees a request for GET /orders/124, and simply changes the number: GET /orders/125, 126, 127. If the server returns each one, they can walk the entire order table, other customers' addresses, amounts, and items, without ever touching an admin function. If you have heard this called IDOR (insecure direct object reference), it is the same bug; OWASP renamed it BOLA for the API context. Identifiers do not have to be sequential integers, either. UUIDs assumed to be unguessable, references buried in a request body, and IDs resolved through nested GraphQL fields are all BOLA surface.

What is BFLA (Broken Function Level Authorization)?

BFLA is a failure to check that the user is allowed to perform that action at all. Where BOLA is about data you should not see, BFLA is about functions you should not be able to call. A standard user finds the admin routes, DELETE /users/89, POST /admin/refunds, PUT /accounts/settings/global, and simply calls them with their ordinary session token. If the server executes the request because it only checked that you are logged in, not which role you hold, that is BFLA.

It often hides behind the client. The admin button is not rendered in your UI, so the assumption is that you cannot reach the function, but the API endpoint is still live, and nothing stops you from calling it directly. Switching an HTTP method on the same path (GET to DELETE), guessing an undocumented admin route, or invoking a gRPC service method the client was never meant to expose are all ways BFLA shows up.

BOLA vs BFLA: the difference in one line

The quickest way to keep them straight: BOLA crosses between accounts at the same level; BFLA crosses between levels. BOLA is a regular user reaching another regular user's data. BFLA is a regular user reaching an administrator's powers.

Some findings are both at once: an endpoint that is both admin-only and object-scoped can fail on either axis, which is why real testing checks each dimension separately on every operation.

Why scanners miss both

A vulnerability scanner or DAST tool works by firing payloads at inputs and matching responses against a library of signatures. That model is fundamentally blind to authorization, for one reason: authorization is relative. There is nothing wrong with the response to GET /orders/124 in isolation, it is a perfectly valid 200 with a valid order. Whether it is a vulnerability depends entirely on who asked. A scanner sees one request, one response, one identity. It cannot express the question that defines BOLA and BFLA: “should this user be allowed to do this?”

To answer that, you need at least two accounts and a way to compare them, to take a request that is legitimate for user A and replay it as user B, then check whether the server wrongly allows it. That is a stateful, identity-aware, multi-account exercise. It is exactly the shape of testing a signature engine cannot do, which is why these flaws sail straight through automated scans and land in production.

How to actually test for BOLA and BFLA

The method is conceptually simple and mechanically demanding. You authenticate as two or more user types, at minimum two peer accounts (for BOLA) and one low-privilege plus one high-privilege account (for BFLA). Then, for every operation the API exposes:

• For BOLA: take every request that references an object, in the path, a query parameter, or the body, and replay it with the other account's session, substituting object identifiers across accounts and tenants. If account B receives account A's object, that is a confirmed BOLA.
• For BFLA: take every privileged or admin function and call it with the low-privilege token, including method swaps on the same path and routes that are not exposed in the UI. If the action executes, that is a confirmed BFLA.

Doing this by hand across a real API, dozens or hundreds of operations, each with multiple parameters, times several role pairings, is enormous, repetitive work, which is why it so often gets sampled rather than done completely. This is where an agentic API penetration test fits the problem exactly. You provide one bearer token per user type; the agent parses your OpenAPI spec, enumerates every operation, and replays one role's requests as another across the whole surface. Because it is an agentic pentester rather than a scanner, it does not stop at “this looks off”, it confirms the cross-account access actually happened and reports it with the exact request and response that prove it, rated with a CVSS v3.1 vector.

Authorization is the part of API security that pattern matching cannot reach and that manual testing rarely covers exhaustively. Testing it well means treating every endpoint as a question about identity, and answering that question with more than one account. Anything less leaves the most common path into your data untested.

When BOLA and BFLA chain together

The two flaws are often described as separate categories, but in a real attack they frequently chain into a single path, and the chain is usually more damaging than either flaw alone. The common pattern: a BFLA-exposed admin function returns a list or export of objects, and the identifiers in that response become the fuel for a follow-on BOLA read against a completely different endpoint.

A standard user should never reach an admin listing endpoint at all. If that endpoint has a BFLA flaw, that is, it only checks that the caller is authenticated and never checks their role, the attacker gets back a page of records: customer IDs, order IDs, account numbers, whatever the export is built to return. On its own, that response is already a finding. But those identifiers rarely stop there. They are exactly what a second, ordinary-looking endpoint needs to serve up full records one at a time, an endpoint that authenticates correctly but never checks object ownership, a textbook BOLA.

An illustrative request sequence makes the chain concrete:

• Step 1, BFLA (privilege escalation): GET /admin/customers/export called with a standard user's token. The endpoint checks only that a valid session exists, not the caller's role, and returns a paginated list of customer IDs.
• Step 2, harvest: the response body yields object identifiers, for example customer_id: 8841, 8842, 8843, that the standard user was never meant to see.
• Step 3, BOLA (object access): GET /customers/8841/profile, then 8842, then 8843, replayed with the same standard user token against a separate profile endpoint that checks authentication but never checks whether the requested customer belongs to the caller. Each call returns full profile data for a customer the attacker has no relationship to.

Illustrative example, not a specific customer result.

Neither endpoint individually looks catastrophic in isolation: the export could be dismissed as a lower-severity access control gap, and the profile read could be mistaken for working as designed since it does return a valid record for a valid ID. The severity only becomes clear once you see the two steps as one path, an unauthorized function that manufactures the exact identifiers an unrelated authorization gap needs. This is also why testing endpoints independently, the way a scanner or a checklist audit does, misses the real risk. An agentic pentester that walks the full call graph, treats output from one operation as candidate input to the next, and replays actual session tokens across the chain is what surfaces this class of finding, and it hands you the two-step request sequence above as the reproduction, not just a pair of unrelated low and medium severity tickets.

References

• OWASP API Security Top 10: API1:2023 Broken Object Level Authorization
• OWASP API Security Top 10: API5:2023 Broken Function Level Authorization
• CWE-639: Authorization Bypass Through User-Controlled Key
• CWE-285: Improper Authorization