BOLA: broken object level authorization in APIs

Definitions follow OWASP API1:2023.

1. The attacker gets a normal account. Signing up, or using a stolen one, gives a valid token.
2. They call the API for their own objects. GET /api/v1/orders/58213 returns their order.
3. They change the identifier. 58214, or an ID seen in another response, a shared link or a mobile app.
4. The API answers. It checked that the token is valid, not that this order belongs to the token's owner.

With a script the same loop runs over thousands of identifiers, which is how BOLA turns into a bulk data leak rather than one exposed record.

They are the same flaw seen from two angles. IDOR is the older name from web applications, where the ID usually sits in a page address or form. BOLA is the name OWASP chose for APIs, where object IDs are in every call and clients, such as mobile apps, expose the full list of endpoints to anyone who looks.

APIs make the flaw more frequent for two reasons. There are many endpoints that each take an ID, and each needs its own check. And the API is often built assuming only the official app will call it, so the checks are left to the app's screens.

Test with two accounts. Record every call the first account makes, swap its token for the second account's, and replay: any call that still succeeds against the first account's objects is BOLA. Include list endpoints, filters and nested routes, not only single-object reads. The wider method is on API security testing.

In live logs, the signal is one caller requesting many object IDs, or IDs that belong to other callers. Spotting it needs the API's own data about ownership, so it is usually built into the application's logging rather than in front of it.

1. Check authorisation for the object, not just the caller. Every endpoint that receives an ID confirms the caller may act on that object.
2. Derive the owner from the token. Look the object up through the authenticated user, never through a user ID sent in the request.
3. Use one authorisation layer. A shared policy check is easier to keep complete than code in every handler.
4. Prefer random identifiers. UUIDs slow enumeration; they do not replace the check.
5. Write tests that call across accounts. Make a failing cross-account call part of the test suite for each endpoint.

An API gateway can validate tokens and schemas, but it rarely knows who owns object 58214. The check belongs where the data is. The rest of the picture is on API security.

A request filter cannot recognise BOLA: the request is authenticated, the ID is a valid number, and nothing in it is an attack pattern. It can still remove other risks from the same endpoints, such as injection in the ID field.

Rate limits help in one specific way. BOLA is usually exploited by walking through many IDs, and limiting how many requests one client makes per minute slows that walk and makes it visible. It narrows the damage; the fix is still in the API.