IDOR / BOLA

What is IDOR / BOLA?

IDOR and BOLA name one flaw: the application lets a user reference an object directly, by an ID in the URL, a request body or a token, and does not verify that this user may access that object. Change GET /api/orders/1042 to /api/orders/1043 and you read someone else’s order. Change the userId in a PUT body and you edit someone else’s profile. Insecure Direct Object Reference is the term from the 2007 and 2013 OWASP Top 10; Broken Object Level Authorization is the name the OWASP API Security Top 10 gave it in 2019 and kept as API1:2023, the number one API risk.

The underlying weakness is CWE-639, Authorization Bypass Through User-Controlled Key. The bug is not that the ID is visible or predictable; it is that the server trusts the ID instead of checking ownership.

Where is it defined?

The OWASP API Security Top 10, API1:2023 Broken Object Level Authorization, gives the definition, examples and prevention. The 2021 OWASP Top 10 folds it into A01 Broken Access Control. The OWASP Web Security Testing Guide describes the test procedure under WSTG-ATHZ-04, Testing for Insecure Direct Object References. MITRE’s CWE-639 and the broader CWE-284 (Improper Access Control) are what SAST tools and scanners report against. A close relative, API3:2023 Broken Object Property Level Authorization, covers the case where the object is yours but the server lets you read or write fields it should not (mass assignment, excessive data exposure).

What it means in practice

BOLA is the finding we report most often in web, API and mobile backend tests, and it is almost always High or Critical. Patterns from projects:

• Sequential IDs make it worse, not possible. Switching to UUIDs limits enumeration but does not fix the authorisation check. An attacker who obtains one UUID (from a shared link, a log, a second account) still gets in.
• Mobile and IoT backends are the worst affected. The app shows only your devices, so developers assume the API does too. In tests of consumer appliance cloud APIs we have repeatedly seen that changing the device serial or ID in a request gave read or control access to another household’s device. The pattern repeats across robot vacuums, irrigation controllers and chargers.
• Multi-step flows hide it. The list endpoint filters correctly; the detail or export endpoint does not. Every endpoint that takes an ID needs its own check.
• Scanners cannot find it. Each request is valid HTTP with a valid session. Finding BOLA takes two accounts, every endpoint and a tester who swaps IDs systematically. Authorisation tests are therefore a fixed part of our API test plan.

The fix is a server-side authorisation check on every object access, implemented once in a central layer (a policy function or an ORM scope that always filters by tenant and owner) rather than per endpoint, plus automated tests that assert user A cannot read user B’s objects.

Common misunderstandings

IDOR is not an information disclosure of IDs; exposing an ID is fine if the server checks access. It is not fixed by authentication; the attacker is logged in. And it is not an input validation issue: the ID is perfectly valid, it simply belongs to someone else.