Where API Authorization Leaks: Checking BOLA, BFLA, and Token Bypass With Two Accounts | GOTROOT

APIs quietly carry data behind the screen, so the most critical API flaw is often not flashy injection but authorization. “Should this person make this request?” is a business rule, which a scanner can’t judge as right or wrong — that’s why it’s both the most common and the most-missed class. This is a calm look at how we find authorization issues, with real request examples.

The core: two-account differential testing

The starting point is simple. Prepare two accounts of different privilege (A and B) and check whether A’s session reaches B’s data or functions. Tools like Burp’s Autorize replay A’s requests with B’s token and show the difference at a glance.

BOLA / IDOR — object-level authorization

The most common API flaw. We test whether changing an identifier reaches another user’s object.

# request account B's order (124) using account A's token
GET /api/v1/orders/124 HTTP/1.1
Authorization: Bearer <A_TOKEN>

# 200 + someone else's data → BOLA (should be 403/404)

Even “unguessable” UUIDs often leak via other responses, logs, or enumeration, so identifier randomness is no substitute for authorization. We cover write/delete (PUT/PATCH/DELETE) and nested resources (order→payment→card), not just reads.

BFLA · Mass assignment

We check whether a normal user can invoke admin functions (BFLA), and whether the request body can overwrite privileged fields (mass assignment).

PATCH /api/v1/users/me HTTP/1.1
Authorization: Bearer <A_TOKEN>
Content-Type: application/json

{"nickname":"x","role":"admin","is_verified":true}
# if role / is_verified take effect, it's mass assignment

Can a token be forged?

API authorization ultimately rests on token validation. With JWTs we test algorithm confusion (alg:none, RS256→HS256 key confusion), missing expiry/signature checks, and key injection via kid. We also check state-sensitive endpoints (one-time coupons, balance deduction) for constraints that loosen under concurrent requests (race conditions).

Going deeper — token libraries and components

Authorization isn’t only about your own code. If a JWT-validation library, API gateway, or serialization component you lean on carries a known flaw, it becomes a bypass. Targeted attackers (APT) aim there too, so we fingerprint the components and versions in use and confirm, within a controlled scope, whether a known flaw (1-day) is actually exploitable here. (Related: How 0-days Are Found)

What we look at

• Differential-compare every endpoint with 2+ accounts of different privilege

• Cover write/delete and method tampering, not just reads

• Identifiers: numeric, UUID, nested, GraphQL node

• Tokens: expiry, signature, algorithm, scope enforcement

• State endpoints: concurrency (race) tests

Field note: authorization is ultimately the business question, “should this request be allowed?” The answer needs human context — so however good automation gets, this area seems to need one more layer of human checking.

FAQ

Test APIs separately?

APIs differ from the web UI in threat model and authorization, so dedicated scenarios and a multi-account setup help. We recommend covering them together.

Are UUIDs safe from BOLA?

Unfortunately not — UUIDs can leak by other paths, so identifier randomness is no substitute for authorization.

Closing

A single API authorization flaw can lead to mass data exposure, which is exactly why calmly checking each boundary with two accounts matters. To validate your API’s real authorization boundaries together, reach out at API penetration testing.