Broken Object Level Authorization (BOLA) is an API flaw where a user can access another user's data by changing an object identifier in a request, because the server checks that the caller is logged in but not that the object belongs to them. OWASP ranks it first in its 2023 API Security Top 10.
Why is it hiding in plain sight?
Everything looks correct. The caller has a valid token. The endpoint is meant for users like them. The request is well formed. The only wrong thing is the identifier.
OWASP explains why it is so common: the server usually does not track the client's state and relies on parameters, such as object IDs sent by the client, to decide which objects to access. The IDs can be sequential integers, UUIDs or generic strings, and they are easy to spot in the path, query string, headers or body. OWASP rates exploitability as easy and prevalence as widespread.
The impact can be data disclosure, data loss or data manipulation, and in some cases full account takeover.
What do real patterns look like?
OWASP gives three scenarios that show the range:
- An e-commerce platform exposes revenue charts through an endpoint patterned on the shop name. Anyone who can list shop names can swap them in and read sales data for thousands of shops.
- A car maker's mobile API lets a driver start the engine and lock the doors by sending the vehicle identification number. The API does not check that the vehicle belongs to the logged-in user.
- A document service deletes a document by ID through a GraphQL mutation with no permission check, so one user can delete another's document.
Notice that the third example is not about reading data. Write and delete operations are also object-level actions.
How is BOLA different from other access flaws?
OWASP draws a line. In BOLA the user is meant to have access to the endpoint, and the violation is at the object level, through the ID. If an attacker reaches an endpoint or function they should not reach at all, that is Broken Function Level Authorization, a different category.
It also warns that comparing the user ID from the session, for example one extracted from a token, with the ID in the request is not a sufficient general solution. That approach handles only a small subset of cases. Real systems have shared documents, teams, delegated access and admin roles, so the check needs a policy, not a string comparison.
A constructed example
A clinic scheduling API has an endpoint to fetch an appointment by number. The code loads the appointment and returns it. A developer later adds a staff view, and a patient token also works on it. A tester signs in as patient A, loads appointment 5001, then asks for 5002, 5003 and so on. Each returns another patient's name and reason for visit. No scanner flagged it, because the responses were valid and the status code was 200.
How do you prevent it?
OWASP's guidance is plain:
- Implement an authorization mechanism that relies on user policies and hierarchy.
- Use it in every function that takes an input from the client to access a record in the database, checking that the logged-in user may perform the requested action on the record.
- Prefer random, unpredictable values as record identifiers. This makes guessing harder but is not a substitute for checks.
- Write tests that evaluate the authorization mechanism, and do not deploy changes that make the tests fail.
How to check or apply this
- List every endpoint that takes an identifier in the path, query, header or body.
- For each, write the rule in one sentence: who may read, change or delete it.
- Centralize the check, such as a shared function that takes the user, the action and the object, so developers cannot forget it.
- Create two test users and two sets of data. Add automated tests where user A tries to read, update and delete user B's objects through every endpoint, and fail the build on success.
- Include batch and GraphQL operations in the test list, since they often accept many IDs at once.
- Log denied object access attempts and alert on one user hitting many different IDs in a short time.
Quick check
Do UUIDs prevent BOLA?
No. They make guessing harder, but identifiers leak through URLs, logs and other responses. OWASP lists random IDs as a helpful extra, with the authorization check as the real fix.
Will a web application firewall stop BOLA?
Unlikely. The requests are valid and come from signed-in users. Only the application knows who owns an object.
Sources
Last reviewed: 18 October 2026.
