Broken Object Level Authorization (BOLA) is a critical API vulnerability that occurs when an application fails to properly verify whether an authenticated user is authorized to access a specific resource. Instead of enforcing authorization checks at the server-side, the API blindly trusts object identifiers (such as user IDs, order IDs, or account numbers) supplied by the client.
According to the OWASP API Security Top 10 (2023), BOLA is ranked as the #1 API vulnerability due to how common, easy to exploit, and highly impactful it is. Attackers can exploit this vulnerability by simply modifying these identifiers in API requests to access other users' data. In many cases, no advanced exploitation is required, just a valid session or token and the ability to guess or enumerate object IDs. Successful exploitation of BOLA vulnerability can result in sensitive data exposure, account takeovers, privilege escalation, and even financial fraud.
It is worth noting that in traditional web application security testing, BOLA is known as IDOR (Insecure Direct Object Reference). Both terms describe the same problem: missing authorization checks when accessing objects.
How Does BOLA Happen?
APIs often expose object identifiers (such as user IDs, order IDs, or account numbers) in client requests. When these identifiers are not protected by strict, server-side authorization checks, the API may allow users to access objects they do not own.
Here are common API design patterns that cause this vulnerability:
- Insufficient authorization checks The API confirms the user is logged in but doesn't verify they own the requested resource. While authentication verifies who a user is, authorization determines what that user is allowed to do.
- Predictable identifiers The use of guessable identifiers (for example,
12345,12346) makes it easy for attackers to modify requests and test access to other users' data. - Over-reliance on client input The API assumes that object identifiers provided by the client are valid and belong to the authenticated user, rather than validating ownership on the server side.
- Authorization gaps in complex architectures In microservices or distributed systems, one service may enforce authorization checks while downstream services assume those checks have already been performed, creating exploitable gaps.
Here's an example: Exposure via Account Number
GET /transactions/29913100395
Authorization: Bearer <user1_token>In this request, 29913100395 is the account number of User 1. Using their valid token, User 1 could view their own transaction history as expected.
The vulnerability occurred when the same token was used to request a different account number:
GET /transactions/7620846220
Authorization: Bearer <user1_token>The API returned the transaction history for this other account, exposing sensitive data for a user who was not authorized.
This happened because the server fails to properly enforce authorization and trusted any account number provided by the client and did not verify whether the authenticated user actually owned the requested account. As a result, attackers could enumerate account numbers and access other users' transaction histories without needing additional credentials.
Real-World BOLA Breaches
- Uber Application Breach In 2019, Uber's API was discovered to allow authenticated users to perform actions on accounts not belonging to them. By altering the userID in an API request, attackers could control other users' profiles and even order rides on their behalf, resulting in potentially full account takeover.
- Brazilian Dating App
Security researchers identified a Broken Object Level Authorization (BOLA) vulnerability in a newly launched dating app in Brazil that allowed unauthorized enumeration of user IDs. As a result, the personal data of approximately 17,000 users was exposed, including names, birthdates, and ID verification selfies. Following the disclosure, the app shut down its operations to contain the issue and secure user data.
How to Prevent BOLA
- Always check authorization at the object level Don't just verify the user is logged in, confirm they own the resource.
- Don't trust client-supplied IDs Use server-side checks and secure tokens.
- Make IDs hard to guess Use random or UUID-based identifiers instead of sequential numbers.
- Apply consistent checks across all services Especially in microservice architectures.
- Test for BOLA during development Try changing IDs in requests to see if unauthorized data is exposed.
Conclusion
Broken Object Level Authorization (BOLA) is a simple yet critical vulnerability that happens when applications fail to properly verify whether a user is allowed to access certain data. Despite its straightforward nature, BOLA has been at the heart of numerous high-profile security incidents, where even small oversights led to the exposure of sensitive information. Understanding how BOLA works is the first step to securing your APIs, the next step is designing APIs that enforce strict and consistent authorization checks. Doing so not only protects user data but also preserves trust and helps prevent costly security breaches.