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 broken object level authorization:‍

 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.