Subscribe to our blog.

Subscribe Now

API1:2023 Broken Object Level Authorization (BOLA)

Stephanie Best
Jun 6, 2023

APIs often expose endpoints that handle object identifiers, creating a wide potential attack surface. Object level authorization is an access control mechanism usually implemented at the code level to validate a user’s ability to access a given object. Authorization and access control mechanisms in modern applications are complex and widespread. Even if an application implements a proper infrastructure for authorization checks, developers often forget to apply these checks before accessing an object.

Attackers can easily exploit API endpoints that are vulnerable to broken object level authorization (BOLA) by manipulating the ID of an object that is sent within an API request. This is because the server component usually does not fully track the client’s state. Instead, the server component usually relies on parameters like object IDs sent from the client, to decide which objects can be accessed.

BOLA vulnerabilities are present in around 40% of all API attacks and are listed as the number one threat to API security in the OWASP API Security Top 10. Any access to unauthorized data is severe, regardless of its data classification or data sensitivity. Unfortunately, these types of authorization flaws are not easily detectable with automated static or dynamic testing.

Every API endpoint that receives an ID of an object, and performs any type of action on the object, should implement object level authorization checks. These checks should be made continuously throughout a given session to validate that the logged-in user has access to perform the requested action on a requested object.

Get your copy of the Gartner report: "Innovation Insight for API Protection"

What’s the Potential Impact of a BOLA attack?

Failure to enforce authorization at the object level can lead to data exfiltration as well as unauthorized viewing, modification, or destruction of data.  BOLA can also lead to full account takeover such as in cases where an attacker can compromise a password reset flow and reset credentials of an account they aren’t authorized to.

In the example above, the backend logic of the application queries the database with the userId in the query parameter while verifying the authorization with the userId in the cookie. Under normal conditions, these two values should match. However, an attacker could simply modify the userId value in the query parameter in order to access unauthorized data.

The attacker (John Smith) is logged in with userId 207939055 . When the attacker changed the userId in the query parameter to userId 207938044 , the application did not validate that the userId of the authenticated user matches that of the record being requested in the query parameter or whether the authenticated user is authorized to view that given record. As a result, the database backend returns the record for David Miller as opposed to John Smith.

If the userIds are sequential, the attacker can simply enumerate the query parameter userIdvalue to scrape, or exfiltrate, large amounts of data, particularly if rate limits aren’t enforced.

Real-World Examples of Broken Object Level Authorization (BOLA) Vulnerabilities

How a Hacker Could’ve Taken Over your Uber account

In 2019, a security researcher disclosed a BOLA vulnerability that would have enabled an attacker to take over any user account on Uber. By exploiting the vulnerability, the attacker could access another user’s account to track the target user’s location, take rides, and more. The attacker could also exploit the BOLA vulnerability to harvest Uber mobile app access tokens, and then use those access tokens to take over Uber Driver and Uber Eats accounts. The Uber application userId could be easily enumerated by supplying a user’s phone number or email address in another API request.

The BOLA Attack at the Central Bank of Russia

One prominent example of a successful BOLA attack happened at Russia’s central bank in 2016, where attackers managed to change an account ID and make unauthorized transfers to other accounts via a Fast Payments System, managing to steal around 2 billion rubles.

In this instance, the attackers managed to obtain customer account data by exploiting the BOLA vulnerability, then launched the bank’s mobile application in debug mode, logged in as a real client and transferred funds to another bank. Before making the transfer, the attacker changed the account ID to another client’s ID allowing the transfer to be processed without proper ID verification.

Why Existing Tools Fail to Protect You Against BOLA Vulnerabilities

Traditional security controls like WAFs and API gateways miss these types of attacks because they don’t understand API context and don’t baseline normal API usage.

When it comes to BOLA vulnerabilities, these tools do not know that the userId in the query parameter and the userId in the cookie should match. Also, since this is not a known, predictable attack pattern like a code injection where basic pattern matching and message filtering can be employed, a BOLA attack cannot be identified by the signatures used by a WAF or API gateway.

How to Protect APIs Against Broken Object Level Authorization (BOLA) Attacks

In order to prevent BOLA attacks, an API security solution must be able to learn the business logic of an API and detect when an authenticated user is trying to gain unauthorized access to another user’s data. Effectively, the API security tool needs to be able to recognize that the two objects should match and that the authenticated user is authorized to access the requested object. This kind of detection requires the analysis of large amounts of API traffic in order to gain context and understand the normal behavior of each API.

Only a solution that provides a baseline of normal usage can identify abnormal behavior like an attacker manipulating the userId in a query parameter in GET requests, or a userId variable within a message body of POST requests.

To see how the Salt platform can help you prevent BOLA attacks, get a demo today.

Go back to blog

Download this guide for advice on evaluating key capabilities in API Security

Learn everything you need to know to keep your APIs secure

We have updated and re-designed our Privacy Policy as of  March 2024 to make it easier to understand how we collect and use your personal data.

Get the guide
Read the new policy
Back