Broken object-level authorization (BOLA), also called IDOR, happens when an API lets a user access objects they should not, simply by changing an identifier in a request. It is the top API security risk because it is easy to exploit and exposes other users’ data directly. It is about authorization, checking what you are allowed to access, not authentication.
What broken object-level authorization is
APIs work by letting clients request specific objects: a user record, an order, a document, usually identified by some kind of identifier in the request. Broken object-level authorization happens when the API returns the requested object without properly checking that the user making the request is actually allowed to access that particular object. Change the identifier, and you get someone else’s data.
It is often called IDOR, insecure direct object reference, and the two terms describe the same underlying problem. Whatever the name, the flaw is a failure to enforce ownership: the API confirms who you are, but not that this object is yours to see.
How it differs from broken authentication
This distinction is important, because the two are easily confused. Authentication is about identity: proving who you are. Authorization is about permission: determining what you are allowed to do or access. Broken authentication is a failure of the first. Broken object-level authorization is a failure of the second.
You can be perfectly, legitimately authenticated, logged in as yourself with valid credentials, and still exploit broken object-level authorization, because the flaw is not in how you logged in. It is in the API failing to check, on each request, that the specific object you are asking for belongs to you. That is why an ordinary, authenticated user can often exploit it without any special access.
Why it tops the API risk list
Broken object-level authorization consistently ranks as the most significant api security testing risk, and the reason is a combination of how easy it is to exploit and how much it exposes. Exploiting it can be as simple as changing a number in a request and seeing another user’s record come back. No sophisticated tooling, no complex chain, just an identifier swapped for another.
And what it exposes is other users’ data, directly and at scale. An attacker who finds a BOLA flaw can often iterate through identifiers to harvest large numbers of records. Easy to find, easy to exploit, and high impact: that combination is exactly why it sits at the top of the list.
Why it is so common in APIs
APIs are especially prone to this flaw because they are built around exposing objects by identifier, and because the authorization check has to be made correctly on every single object access. It is easy for developers to implement authentication well, then assume that being logged in is enough, and forget to check ownership on each request. One endpoint enforces the check, another added later does not.
The scale of a modern API, with many endpoints exposing many objects, multiplies the opportunities to miss a check. Attackers only need to find one endpoint where the ownership check is absent.
How to prevent it
The prevention is conceptually simple: enforce authorization on every object access. For each request, the API must confirm not just that the user is authenticated, but that they are actually permitted to access the specific object requested. This check must be applied consistently, on every endpoint, for every object.
The difficulty, as with many api vulnerability, is consistency rather than concept. Ensuring that every endpoint, including new ones added over time, enforces per-object authorization correctly is what prevents BOLA, and what is easy to let slip.
Why validated testing is the only way to be sure
Because broken object-level authorization depends on whether each endpoint actually enforces ownership, the only reliable way to know your API is safe is to test it as an attacker would: authenticate as a user and attempt to access objects belonging to others, across your endpoints, to see whether the checks hold. That validated testing proves whether the flaw exists, rather than assuming the checks are all in place.
And because APIs change constantly, with new endpoints and objects added regularly, that validation needs to be ongoing. A clean result last quarter says nothing about the endpoint shipped last week.
To confirm whether your APIs enforce object-level authorization correctly, explore our API security capability, or read how continuous service validation keeps that assurance current as your APIs evolve.
For the wider list, see the OWASP API Security Top 10, where broken object-level authorization ranks first.
Frequently asked questions
What is broken object-level authorization?
It is an API flaw, also called IDOR, where a user can access objects they should not by changing an identifier in a request. The API confirms who the user is but fails to check that the specific object requested actually belongs to them.
How is it different from broken authentication?
Authentication is about identity, proving who you are, while authorization is about permission, what you are allowed to access. Broken object-level authorization is a failure of authorization, so a fully authenticated, legitimate user can exploit it by requesting objects that are not theirs.
Why is it so common in APIs?
APIs are built around exposing objects by identifier, and the ownership check has to be made correctly on every object access. It is easy to implement authentication well but forget per-object authorization on some endpoints, and attackers only need to find one that misses the check.
How do you prevent and detect it?
Enforce authorization on every object access, on every endpoint, confirming the user is permitted to access the specific object requested. Then validate by testing as an authenticated user attempting to reach others’ objects, and repeat that testing as the API changes.
