Skip to content

What is BOLA?

Broken object level authorisation, or BOLA, is when an API returns or changes an object without checking that the caller is allowed to touch it. An attacker changes an identifier in the request and reads someone else's data. It is the first risk in the OWASP API Security Top 10.

How it works

A banking app shows a signed-in customer their statements with one call:

GET /api/v1/accounts/48213/statements
Authorization: Bearer <token for customer A>

Customer A changes 48213 to 48214 and sends the request again. The API checks that the token is valid and that the caller may read statements. It never checks that account 48214 belongs to customer A. It returns another customer’s statements with 200 OK.

An attacker scripts the change and walks the range of account numbers. Every request is authenticated and well formed. The data leaves one valid response at a time.

BOLA is listed as API1 in the OWASP API Security Top 10 (2023).

Why classic controls miss it

  • A web application firewall looks for malicious payloads. A changed account number is a valid value in a valid request.
  • Authentication passes, because the attacker is a real, signed-in user.
  • Rate limits rarely fire. Enumeration can run slowly, or spread across sessions and addresses.
  • The flaw lives in business logic. Only the application knows who owns account 48214.

How to detect and prevent it

  1. Check ownership on every object access, on the server. Ask “may this caller touch this object?” and never trust an identifier sent by the client.
  2. Put the check in one place: a shared authorisation function or policy that every endpoint calls, so new endpoints cannot skip it.
  3. Use random identifiers rather than sequential ones. This slows enumeration; it never replaces the ownership check.
  4. Test with two users. User A requests user B’s objects and must receive 403 or 404.
  5. Watch your logs for one caller touching many object IDs in sequence, a success after a run of denials, and identifiers that never appeared in that caller’s own responses.

How Cyron handles it

Cyron API Security has dedicated detection for API1: sequential-ID scanning, bulk enumeration of resources, a success after repeated failures and manipulated identifiers. Behavioural intelligence learns a baseline for each endpoint and follows whole sessions, so enumeration built from valid requests stands out. When an attack is confirmed, iris, the eBPF kernel agent, blocks the source at the kernel. See how Cyron API Security works.