Key takeaways

  • BOLA is the number one risk in the OWASP API Security Top 10 2023, and it is common because every endpoint that takes an object ID can carry it.
  • The flaw lets a signed-in user change an identifier in a request and read or change another user's data.
  • Hard to guess identifiers help a little but are not a fix. The server must check ownership on every request.
  • Put the authorization check in one shared place, and test it with two accounts in automated tests.
  • Review logs for one account requesting many different object IDs.

Start with the answer: broken object-level authorization, or BOLA, is when an API lets a user reach an object, such as an invoice, an order or a medical record, that belongs to someone else, because the server never checks that this user may access this object. The fix is to check ownership or permission on the server for every request that uses an object identifier, every time.

How it works

Consider a mobile app that shows your orders. It calls an endpoint that includes an order number, and the server returns the order. You are signed in, so the server knows who you are. If the server does not also check that order 1002 belongs to you, then you can change the number to 1003 and see someone else's order. That is BOLA. The attacker needs no special tools, only a valid account and the ability to edit a request.

OWASP lists this as API1:2023 and notes that APIs tend to expose many endpoints that handle object identifiers, which creates a wide attack surface. Object-level checks should be in every function that accepts an ID from the client and uses it to reach a data source.

Authentication is not authorization

Authentication answers who you are. Authorization answers what you may do. Many BOLA bugs appear because a team did the first well and assumed that was enough. A valid token proves identity, not rights to every object. The server needs a rule for each type of object: who may view it, change it or delete it.

Where the identifier hides

  • In the path, such as an order number in the address.
  • In the query string or a form field.
  • In the body of a JSON request, including nested objects.
  • In headers or cookies.
  • In batch or GraphQL requests that fetch many objects at once, where a check may be applied to the first item only.

Why random IDs are not enough

Some teams switch from counting numbers to long random identifiers. That makes guessing harder, but OWASP is clear that this is not a replacement for an authorization check. Identifiers leak through logs, emails, shared links, referrer headers and other API responses. Once an attacker holds a valid ID, only a server-side check stops them.

How to find it

  • Create two test users in two tenants. Capture a request as user A that fetches an object. Replay it with user B's token. If it works, you have BOLA.
  • Repeat for every method: read, update, delete and any action endpoint.
  • Try IDs from other tenants, deleted objects and objects in other states.
  • Review the code for endpoints that load a record by ID without a filter on the current user or tenant.
  • Run the same tests in your automated pipeline so a regression is caught the day it appears.

How to prevent it

OWASP's guidance comes down to a few habits.

  • Implement an authorization policy based on user roles and relationships and check it in every function that uses an ID from the client.
  • Take the current user from the session or token, not from a field in the request. Do not trust a user ID sent by the client.
  • Scope queries by owner or tenant, for example by loading a record with both its ID and the current account, so a record outside the account simply is not found.
  • Centralize the check in shared middleware or a policy layer, so developers cannot forget it on a new endpoint.
  • Use hard-to-guess identifiers as an extra layer, not as the main control.
  • Write tests that exercise authorization failures, not only successful requests.

Detect and respond

Log every authorization failure with the account, the object and the route. Alert on patterns that look like enumeration, such as one account requesting hundreds of different IDs in a short time, or many not found and forbidden responses. Rate limits slow an attacker, but they do not fix the flaw.

Why it matters to the business

A BOLA flaw often means one customer can read another customer's data. That can trigger breach notice duties, contract claims and loss of trust. It is common in portals, mobile apps and partner integrations built quickly. A short security review before launch is cheaper than a notification letter.

Our team reviews APIs for authorization flaws, builds test cases into your pipeline and helps development teams put the checks in the right place.

Sources

This article is general information, not legal advice. Standards and vendor documentation change; confirm current requirements with your regulator, counsel and IT provider. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity