What is BOLA? The #1 OWASP API vulnerability explained

BOLA happens when an API endpoint identifies an object (a user, an invoice, a document) by an identifier in the request, authenticates the caller, but fails to check whether that specific caller is allowed to access that specific object. The endpoint says "sure, here is the data" to anyone who is logged in, regardless of whether the data belongs to them.

The canonical example:

GET /api/users/123/profile
Authorization: Bearer <token-for-user-456>

200 OK
{ "id": 123, "email": "alice@example.com", "ssn": "..." }

User 456 is authenticated but is requesting user 123's profile. The endpoint should return 403 Forbidden; instead it returns 200 and hands over Alice's data. That is BOLA. Replace /users/123 with /invoices/123, /documents/abc, or /api/v1/accounts/9981 — the pattern is the same.

The exploit, in the worst case, is a script that increments the identifier and dumps every object. That is exactly what happened in the highest-profile cases.

You will see both terms used interchangeably. IDOR — Insecure Direct Object Reference — is the older term, popularised by the OWASP Top 10 for web applications in 2007 and 2013. BOLA is the term OWASP adopted when it published the dedicated API Security Top 10 in 2019, recognising that the same logic class behaves differently in API contexts than in HTML web apps.

Functionally they are the same vulnerability. Both involve passing an object identifier in a request and failing to authorise the caller against that object. The fix is the same: authorise every object access, not just authenticate the caller.

Most automated web scanners look for patterns in request and response: a SQL injection payload that triggers a database error, an XSS string that gets reflected, a directory traversal that returns /etc/passwd. BOLA has no such pattern. A BOLA request looks exactly like a legitimate request — same structure, same headers, same content type. The only thing that distinguishes a malicious BOLA request from a legitimate one is the business logic: does this token own this object?

That logic lives in your application code. A scanner cannot derive it from outside. Even with authenticated scanning, the scanner needs at least two user contexts (test user A and test user B) and the knowledge of which objects belong to which user, in order to generate a BOLA test by requesting B's object with A's token. Most off-the-shelf DAST tools do not do this well.

The practical consequence is that BOLA is usually found one of three ways: a manual pentest with a skilled tester, a custom test suite written by the development team, or a breach.

The Optus breach of September 2022 — one of the largest data exposures in Australian history — has become the canonical teaching example for BOLA. According to public reporting and statements from the company and Australian regulators, an exposed customer-facing API endpoint accepted incrementing customer identifiers, performed no proper authorisation check, and allowed an attacker to enumerate the personal data of approximately 9.8 million customers including names, dates of birth, addresses and government identification document numbers.

The technical pattern was textbook BOLA: the API authenticated (or did not require auth at all, in some accounts), accepted the identifier, did not check ownership, returned the record. Repeat in a loop, change the number, dump everything.

The lesson for engineering teams is uncomfortable: the bug was simple, single-file, findable by any developer who knew to look — and it sat in production long enough for a third party to extract a country's worth of customer records.

Detection breaks into three approaches, in descending order of confidence:

1. Manual pentest with two users. A skilled tester creates two test accounts, identifies endpoints that take object IDs in paths or bodies, and systematically attempts to access user A's objects with user B's token. This is expensive (a senior tester, several days) but is the gold standard. Annual pentests are the right cadence for most teams.
2. Custom integration tests in your CI pipeline. Write tests that explicitly verify cross-tenant access is rejected. Every endpoint that returns user-scoped data gets a test like user_b_token_cannot_read_user_a_invoice. Cheap once written, catches regressions.
3. Heuristic detection from outside. Parse the OpenAPI / Swagger document or GraphQL introspection schema, identify endpoints that take ID-shaped parameters, flag those for review. This produces a list of candidate BOLA endpoints, not confirmed BOLA endpoints. Useful as a triage feed for #1 or #2; not a substitute.

The most effective programmes combine all three: heuristic detection for breadth, integration tests for regression coverage, annual manual pentest for depth on the high-value endpoints.

The fix is conceptually simple and operationally stubborn: every endpoint that loads an object by ID must authorise the caller against that object before returning it.

Practical guidance:

• Centralise authorisation in a single function or middleware rather than scattered if user.id == obj.owner_id checks in controllers. Centralised checks are testable and harder to forget.
• Default to deny. New endpoints should refuse access unless an authorisation rule explicitly permits it.
• Prefer opaque, hard-to-guess identifiers (UUIDv7, ULID) over sequential integers for any externally exposed ID. This does not fix BOLA but raises the effort to exploit it — sequential IDs are trivially enumerable, UUIDs are not.
• Log object-level access. If a BOLA does slip through, access logs let you scope the impact and notify.
• Test cross-tenant access in CI. The test is short, the protection is durable.

CyberScore approaches BOLA conservatively because we are a passive external scanner. We do not authenticate to your API, we do not send payloads, and we do not attempt to exploit anything. Within those limits, here is what we do:

• Look for publicly exposed OpenAPI / Swagger documents (/swagger.json, /openapi.yaml, common variants) and parse the schema.
• Probe for publicly accessible GraphQL endpoints with introspection enabled (/graphql, /api/graphql). An exposed introspection surface is already a finding in itself.
• Identify endpoints and types that take ID-shaped parameters (path segments matching /[a-z]+/(\\d+|[a-f0-9-]{36}), query params like user_id, account_id, doc_id).
• Flag those endpoints as BOLA candidates requiring authorisation testing.

What we do not do: try /users/1, /users/2, etc., to see if an unauthenticated request returns data. That would be active probing of customer infrastructure, which violates our passive-only stance (see security page and methodology). Our BOLA finding is a yellow flag for the engineering team to investigate, not a proof-of-concept exploit.

For full BOLA validation you need an authenticated DAST tool (Burp Suite Pro with user-context scripting, or Acunetix with two-user macros), a manual pentest, or an in-house test suite with two distinct user contexts.