Broken Object Level Authorization (BOLA) | OWASP API1:2023
A Guide to Broken Object Level Authorization (BOLA)
Broken object level authorization, or BOLA, occurs when an API endpoint performs an action on an object using a client-supplied ID without verifying that the requesting user actually has permission to access that specific object.
Object IDs show up everywhere in API traffic: integers in a URL path, UUIDs in a query string, strings buried in a request payload. Every one of those parameters is a potential BOLA target. An endpoint that trusts the ID and skips the ownership check hands any authenticated (or sometimes unauthenticated) user a way to read, modify, or delete records that belong to someone else.
BOLA is distinct from broken function level authorization (BFLA). BOLA involves reaching objects a user shouldn’t see. BFLA involves calling functions a user shouldn’t be able to invoke.
Key Takeaways
- Broken Object Level Authorization (BOLA) is ranked #1 in the OWASP API Security Top 10 2023 and is one of the most widespread and easily exploitable API vulnerabilities
- It occurs when an API endpoint performs actions on objects using client-supplied IDs without verifying that the requesting user has permission to access that specific object
- Attackers exploit BOLA by manipulating object IDs, which can be integers, UUIDs, or strings, found in URL paths, query parameters, headers, or request payloads
- BOLA differs from Broken Function Level Authorization (BFLA): BOLA involves access to objects a user shouldn’t see, while BFLA involves access to API functions a user shouldn’t be able to call
- Prevention requires implementing object-level authorization checks on every API endpoint that receives an object ID, and using random, unpredictable values like GUIDs instead of sequential
Why is it Dangerous
BOLA is ranked number one in the OWASP API Security Top 10 2023 for a reason: it is common, easy to find, and easy to exploit. Successful exploitation results in:
- Unauthorized disclosure of other users’ data
- Unauthorized modification or deletion of records
- Full account takeover when the exposed object controls authentication state
- Mass data harvesting through automated ID enumeration
The risk compounds when object IDs are sequential or otherwise predictable, since an attacker iterates through them with no special tooling required.
Typical Manifestations
BOLA commonly appears when:
- An endpoint like /api/invoices/1234 returns any invoice matching that ID, regardless of who owns it
- Object IDs increment sequentially, making enumeration trivial
- Authorization checks exist at the authentication layer but not at the object layer
- Mobile or single-page application clients pass IDs the server trusts implicitly
In all BOLA manifestations, the API has confirmed who the user is but not what that user is allowed to touch.
Preventing BOLA
Object-level authorization has to run on every single request, not just at login. These strategies should be implemented to prevent BOLA.
- Implement a proper authorization mechanism that relies on user policies and hierarchy and use that mechanism to check the logged-in user’s permission on the specific record in every function that takes client input to access a database record
- Use random, unpredictable identifiers such as GUIDs instead of sequential integers
- Write tests that evaluate the authorization mechanism directly, and don’t deploy changes that make those tests fail
BOLA is an authorization failure, separate from authentication. Confirming who a user is says nothing about what that user is allowed to touch; every object-level request needs its own check.
