BOLA vs BFLA vs IDOR: API Authorization Attacks Explained

Three acronyms describe the same kind of failure: an API that says yes when it should say no. They differ in what the attacker reaches, and that difference decides how you detect each one.

What is the difference between BOLA, BFLA and IDOR?

BOLA lets a caller read or change an object that belongs to someone else. BFLA lets a caller use a function their role should never reach, such as an admin endpoint. IDOR is the older, broader name for the BOLA pattern. BOLA is about the wrong data; BFLA is about the wrong action.

BOLA, BFLA and IDOR compared

	BOLA	BFLA	IDOR
Full name	Broken object level authorisation	Broken function level authorisation	Insecure direct object reference
What the attacker reaches	Another user’s record	A function above their role	Another user’s record or file
Typical change to the request	Swap an ID: GET /orders/12346	Call a hidden path or change the method: DELETE /users/42	Swap an ID in a URL, form field or file name
Direction of privilege	Horizontal: same role, wrong data	Vertical: a higher role’s action	Usually horizontal
Where it is classified	API1:2023 in the OWASP API Security Top 10	API5:2023 in the same list	CWE-639; the term predates the API list
Signals in live traffic	Sequential-ID scanning, bulk enumeration, a success after repeated failures, manipulated identifiers	Access to restricted functions, method override, probes of admin paths	The BOLA signals, when it happens through an API
First fix	Check ownership of every object on every request	Deny by default; check the caller’s role on every function	Indirect references plus ownership checks

Broken object level authorisation: the wrong data

Broken object level authorisation occurs when an API checks that a user may perform an action, but not whether they may perform it on this particular object.

The classic example:

GET /api/orders/12345   → Returns your order
GET /api/orders/12346   → Returns someone else's order

The API confirms you are authenticated. It confirms you may view orders. It never checks whether order 12346 belongs to you.

Why it is so common. Developers often handle authorisation at the route level (“users can access /orders”) rather than the object level (“users can access their own orders”). The gap is invisible in normal testing. You only find it by trying to read another user’s data.

Why it matters. BOLA is first in the OWASP API Security Top 10 (2023). Attackers iterate through IDs and collect data they should never see, one valid request at a time.

Broken function level authorisation: the wrong action

Broken function level authorisation occurs when an API exposes administrative or privileged functions to ordinary users.

Examples:

Regular user discovers:
POST /api/admin/users           → Create any user
DELETE /api/users/{id}          → Delete any account
PUT /api/users/{id}/role        → Promote to admin

The API doesn’t properly restrict who can call sensitive endpoints. The functions exist; the attacker just needs to find and call them.

Why it happens. Different endpoints are built by different teams, at different times. Admin APIs are labelled “internal” and assumed to be unreachable. Front-end applications hide the admin buttons, but the APIs behind them stay open.

Common patterns. Changing the HTTP method (GET to DELETE), discovering /admin/ paths, and setting role fields in update requests.

Where IDOR fits

Insecure direct object reference is the older name. It appeared in the OWASP Top 10 for web applications from 2007, and it covers any direct reference the server trusts without checking ownership: an ID in a URL, a file name, a database key.

MITRE catalogues the weakness as CWE-639, authorisation bypass through a user-controlled key, and lists both IDOR and BOLA as alternative terms. In an API, IDOR and BOLA are the same attack. OWASP’s API list uses BOLA, which puts the focus on the object.

The signals that reveal each attack

Neither attack carries a malicious payload. Every request is well formed and authenticated, so signatures see nothing. Detection depends on the relationship between callers, objects and functions over time.

BOLA and IDOR signals:

• Sequential-ID scanning. One caller requests /users/1, /users/2, /users/3 in quick succession.
• Bulk enumeration of resources. One caller touches far more objects than their own account holds.
• A success after repeated failures. A run of 403 or 404 responses, then a 200: the ID that worked.
• Manipulated identifiers. Swapped UUIDs, array indexes or encoded IDs that don’t belong to the caller.
• Parameter pollution. Two IDs in one request, hoping the authorisation check reads one and the query reads the other.

BFLA signals:

• Access to restricted functions. Calls to endpoints you have marked as admin-only, from ordinary accounts.
• Method override. Headers or parameters that turn a GET or POST into a DELETE or PUT.
• Unusual methods for the account. State-changing requests from accounts that normally only read.
• Path probing. Requests to /admin/, /internal/ or /management/ from callers who have never used them.

Cyron API Security watches for these signals as part of its dedicated detection for all 10 categories of the OWASP API Security Top 10 (2023). For BFLA, you mark the functions that are restricted, and Cyron detects access to them and method override. Behavioural intelligence adds resource enumeration, sequential probing and parameter pollution as session-level rules, on Essential and above.

Watch the demo

In this demo, an authenticated user of a live API requests their own orders, then starts changing the order ID. Each request is valid, carries a real token and returns a normal response. Nothing in any single request looks wrong.

Cyron sees the pattern across requests: one caller enumerating order IDs that belong to other accounts. It raises a BOLA incident, and iris, the eBPF kernel agent, blocks the source at the kernel. Legitimate traffic carries on at full speed, because Cyron analyses a copy of the traffic out of band.

Prevention strategies

For BOLA:

Check object-level authorisation on every request. Don’t rely on hard-to-guess IDs; attackers will enumerate or leak them. Use indirect references that map to the caller’s own resources. Log and monitor access patterns.

For BFLA:

Define which roles may call each endpoint, and deny by default. Every function needs an explicit permission grant. Don’t assume an endpoint is hidden because the front end never shows it. Audit admin functions regularly.

Test your own endpoints today

1. Create two test users, A and B, each with a few objects.
2. As user A, request user B’s objects. Swap the ID in the path, the query string and the JSON body. Try UUIDs and encoded IDs as well as numbers.
3. As an ordinary user, call every admin route you know of. Then repeat with other HTTP methods and with method-override headers.
4. Check that every refusal is consistent. A 403 for one ID and a 404 for another tells an attacker which IDs exist.
5. Turn each test into an automated check, so a new endpoint cannot ship without it.

BOLA and BFLA are two of ten categories. For the rest, work through the OWASP API Security Top 10 checklist.

Detect authorisation attacks in live traffic

Cyron API Security watches for sequential-ID scanning, bulk enumeration, restricted-function access and method override, on live traffic and out of band. See the pattern as it starts, with the evidence attached to the incident.

Start free

Updated 1 October 2026: new title, a three-way comparison with IDOR, the live-traffic signals for each attack, the BOLA detection demo and a test plan.