BOLA Explained

BOLA is broken object level authorisation: the API confirms you are logged in but never checks that the object you asked for belongs to you. Change an identifier in a request and you read someone else's data. It ranks first in API security because APIs expose object identifiers directly and developers assume the client will not modify them.

Why APIs get this wrong more than web apps

A traditional web application renders a page and simply does not show you a link to another user's invoice. That is not security, but it hides the problem.

An API has no UI to hide behind. The identifier is right there in the URL or the body, the client is expected to send it, and the server has to decide on every single request whether this caller owns this object. Miss that check on one endpoint out of forty and you have a breach.

How to find it

1. Create two accounts. Non negotiable. One account cannot prove an authorisation flaw.
2. Capture as user A. Exercise every feature and log every request that contains an identifier.
3. Replay as user B. Same request, B's session token, A's object id.
4. Read the response carefully. A 200 with A's data is the finding. A 200 with an empty object is still worth investigating.
5. Try every method. GET may be protected while PATCH and DELETE are not. Test each separately.

Practical tip with Burp: keep both sessions open, use Repeater with two tabs, and switch only the token. Changing two things at once wastes the test.

Where it hides

The last two produce the most findings on mature APIs, because the main endpoints get reviewed and the auxiliary ones do not.

Identifiers that look safe and are not

Teams often respond to BOLA by switching from sequential integers to random identifiers. That is an improvement and it is not a fix.

• Identifiers leak through other endpoints: search, listings, notifications, webhooks
• They appear in shared links, emails and logs
• A former employee or ex-collaborator already knows them

Unguessable is not the same as unauthorised. If the only thing protecting an object is that you probably do not know its id, it is not protected.

BOLA and IDOR

Same class of bug, different vocabulary. IDOR is the older web application term, BOLA is the API specific naming. All IDOR is broken access control and so is BOLA. If an interviewer asks for the difference, that is the answer.

Writing it up

Do not report a changed id. Report the impact: how many records reachable, what fields they contain, whether the same flaw allows modification or deletion as well as reading, and what that means under Indian data protection and CERT-In obligations.

Show a masked sample and a count, never real customer data in the report. Structure in how to write a VAPT report.

The fix, and the one developers keep getting wrong

1. Check ownership on every request, in the data layer. Not in a controller, not in middleware that one route skips. Scope the query itself to the caller.
2. Deny by default. A new endpoint should be unreachable until someone writes the authorisation rule.
3. Centralise the check. If each of forty endpoints implements ownership logic independently, one of them is wrong.
4. Test it in CI. An automated test that replays user A's request with user B's token, on every endpoint, catches regressions permanently.

The mistake: treating random identifiers as the fix. It reduces discovery, not access.

Practise this

Take any lab application with two accounts and try to read the other account's data on every single endpoint. Free API challenges on Hacklido.