What is Broken Object Level Authorization (BOLA)?

Broken Object level Authorization is the most common and most severe vulnerability, as stated by OWASP API security project. It is commonly known as BOLA but also referred to as IDOR by many. In this blog, we will explain what it is and how organizations can take measures to prevent BOLA attacks.

BOLA in a nutshell

Let’s understand the authorization process first. In Broken Object Level Authorization, the term ‘object’ refers to a value or a set of values. When a user makes a request via an API to access objects, the developer who has implemented the API, validates at code level if the user has access to those objects. This is a typical authorization process. BOLA means that this authorization process is broken i.e. the user can get access to objects that the user isn’t authorized to. This could lead to a user accessing sensitive data, manipulating data, or executing functions the user should not have access to.

A recent high profile BOLA attack example is of Florida state tax website. Florida state tax website is the state's business tax registration website. The attacker manipulated the application numbers of taxpayers of Florida state and was able to retrieve highly sensitive information of taxpayers including bank account numbers, routing numbers and social security numbers.

How can an attacker exploit BOLA ?

An attacker can exploit BOLA vulnerability by manipulating objects or user identifiers such as IDs and UUIDs.

There are two common types of BOLA:‍

 1. User ID manipulation: An attacker can swap the attacker's resource ID with the victim's resource ID. If the authorization flow described is broken, the attacker can bypass another user's authorization check and gain access to that user’s resources. See example below:

https://www.wallet.com/profile/card_info/?uid=3765

The above API call retrieves the user’s credit card info using the resource "card_info". The object that we are referring to in the Broken Object Level Authorization is the card_info. It is expected that only the only legitimate user can view their card details. After that, we have an important aspect of user identifier, i.e. ?uid=3765. This uid tells the API endpoint which information to retrieve. API endpoint uses the given uid and retrieves the card details and returns it in response.

What if………? 

The attacker changes the uid from 3765 to 3766 and sends the below request.

https://www.wallet.com/profile/card_info/?uid=3766

Surprise ? Attacker can access the card details of another user with UID 3766. This API should have never returned the card details that belonged to another user. The attacker successfully exploited BOLA vulnerability in this API.

2. Object ID manipulation: An attacker can exploit API endpoints by manipulating IDs of an object which is not user’s object sent within the request. This happens when the server does not correctly check if the user is authorized to access that object. For example:

A food delivery app has an endpoint which shows the number of orders delivered and revenue generated every month. The API call to the page looks like this:

https://www.foodapp.com/{restaurant_id}/order_details

This API uses the {restaurant_id} to retrieve and return the order details in the response. The attacker can input any {restaurant_id} in the url which is the object id in this case and send a request. The developer might have forgotten to check if the attacker is authorized to access the details of the restaurant. In that case, the attacker gets unauthorized access to any restaurant’s order delivery and revenue details.

A recent example of BOLA where Object ID was manipulated to exploit the vulnerability is of Florida state tax’s website.

Why should you care?

The successful exploitation of BOLA can lead to unauthorized access to user's data, data loss or data manipulation. If the authorization is missing from critical endpoints such as forgot password endpoint, it could lead to a full account takeover. 

Imagine an attacker is able to retrieve critical details of users such as SSN, credit card information or Address. Attacker can use leaked credit card details leading to potential financial loss.

How to prevent BOLA?

1. ‍Implement clean and robust authorization - All your APIs and users should go through an authorization layer. This mechanism should be implemented in 1 place for all the APIs. Most of the companies think authentication is enough to prevent BOLA attacks. In reality, authentication just checks if the user is signed up on your platform or not. Why clean? More often than not, business priorities change and you will be asked to add/remove permissions for some APIs or users. At this time, the developers should be able to understand the current auth mechanism easily. Rules like /user/* require authorization check using session token, or api/* require authorization check using api-key, /admin/* require user to be an admin are very useful.‍

2. Use secured random UUIDs - Your resource IDs or user IDs shouldn't be guessable - for example, they shouldn't be incremental in nature, or should not be a function or just timestamp. A large unique & securely generated random ID is very hard to guess. The attacker will have to hit and try a lot of values before he lands on a correct one. By this time, either firewall would block or he runs out of resources or it takes a lot of months for the attacker. ‍

3. Continuous Business Logic Security Testing - All your pages and APIs should be checked against BOLA attacks in your CI/CD pipeline. This is arguably the most effective way, but only a handful of tools can understand your business logic and test your APIs for BOLA attacks. Use continuous API security testing tool to do this.