How To Test BOLA by Parameter Pollution Using Akto

In 2016, a security researcher discovered a vulnerability that allowed attackers to bypass Uber's two-factor authentication system and take over accounts by exploiting BOLA via parameter pollution.



6 mins read

The vulnerability allowed attackers to add an additional parameter to the login request, which forced the server to ignore the user's password and allow them to log in without it. This vulnerability affected millions of users and was quickly patched by Uber once it was discovered.

What is Broken Object Level Authorization?

Broken Object Level Authorization (BOLA) is a type of security vulnerability that occurs when an application fails to properly check the permissions of an authenticated user attempting to access a particular resource or object. This can allow an attacker to access or modify sensitive information or functionality that they should not be able to.

What is BOLA by Parameter Pollution?

BOLA by Parameter Pollution is a type of Broken Object Level Authorization vulnerability that occurs when an attacker is able to manipulate or inject multiple instances of the same parameter in the request to bypass authorization checks and gain access to unauthorized resources and objects.

When a backend server receives an API call with multiple instances of the same parameter, the handling varies depending on the specific backend server. Some servers will only consider the first value, while others may prioritize the second value, and some might concatenate both values with a comma as a separator. These variations can introduce security vulnerabilities through which authorization checks could be bypassed.

For example, in the realm of microservices, there is a possibility that the auth-service, which runs on Tomcat, might retrieve the first variable, while the cart-service, powered by PHP, could retrieve the second variable.

How to Manually Test for it

  • Find an API endpoint that performs an action based on the JSON data in the request. The action may or may not include user input.

  • Analyze the parameters in the JSON body and check if any of the parameters are unique to each user. The parameters could include email, userID, cartID, etc., and could be predictable, for example, userID: 23 can be incremented to 24.

  • Inject the same parameter multiple times, but with different values, to analyze the response. If the response contains the data of another user, it means the API endpoint is vulnerable.

Practical Demonstration

Target Application: OWASP Juice Shop

I have created two accounts:

OWASP Juice Shop has an endpoint that enables users to add products to their cart. This endpoint sends three parameters: productId, BasketId, and quantity.

Endpoint: /api/BasketItems/

To view your basket ID, follow these steps:

  1. Right-click on the page and select "Inspect element."

  2. Navigate to the "Storage" tab.

  3. Click on "Session Storage."

  4. Look for the "bid" value, which represents your basket ID.

From the above screenshot, we can see that the bid value is 27 for the victim’s account.

HTTP Parameter Pollution Exploitation

To exploit BOLA via parameter pollution, add another parameter to the JSON body called "basketid," but change the value to 27, which is the victim's basket ID. Basically, we are attempting to add a product to the victim's basket.

The server responded with "success" instead of throwing an unauthorized error. Additionally, we can see that the basketid in the response is 27 instead of 26. This indicates that the exploitation was successful.

We can confirm that the product has been added to the victim's basket. We were able to perform an unauthorized action on the victim's behalf simply by assigning the same parameter that the server was expecting but with a different value.

Problem: You’re Lazy!

What is shown above seems interesting and easy to test, until instead of one endpoint, you have hundreds of API endpoints. This a very tedious task as well as time-consuming.

Test for BOLA using the best proactive API Security product

Our customers love us for our proactive approach and world class API Security test templates. Try Akto's test library yourself in your testing playground. Play with the default test or add your own.

Automation Using Akto

Akto can make this task easier for you by scanning thousands of endpoints with just one click!

If you have not yet installed Akto, you can do so from the Akto GitHub page along with the Akto extension in Burp Suite. For demonstration purposes, we will use OWASP Juice Shop.

Akto Burp Extension

There are multiple ways to create an API inventory in Akto that work in both the Community and Professional editions. There are several ways: import a .har file, including using Postman, AWS traffic mirroring, or forwarding traffic from BurpSuite..

In this case, we are going to create an API inventory through Akto Burp Extension. Simply browse the application and capture all the endpoints.

Once you have your API Inventory, click on “Run Test” and select “BOLA by HTTP Parameter Pollution” from the BOLA section.

In the Testing section, you can see a nice report of the vulnerabilities found. Click on the first endpoint and there you can see the Test Details.

Click on "Original" to view the expected requests and responses, then click "Attempt" to see the modified requests and responses.

Here, Akto added additional parameters, not only basketID but productID and quantity as well. The server response had basketId:8 which is different from the original one. Also, the server responded with 200 OK, indicating successful exploitation.

The best part is that we discovered this with just one click.


  1. Repeated Parameters: Check for repeated parameters and handle them appropriately: HTTP Parameter Pollution occurs when multiple instances of the same parameter are present in a request, leading to potential confusion or ambiguity. To prevent this, implement a mechanism to detect and handle repeated parameters effectively.

  2. Define a JSON schema: Define a schema that describes the structure of the JSON data expected in the request. Use this schema to validate incoming JSON data and reject any data that does not conform to the expected structure. This can help prevent malicious actors from injecting invalid or malicious data into JSON fields.

  3. Decide on a consistent resolution strategy: Determine how to handle conflicting values when multiple instances of the same parameter are present. You can choose to use the first occurrence, or the last occurrence, or implement custom resolution logic based on your application's requirements.

Getting Started

Start your API testing with Akto. You can download it from the GitHub page and follow the instructions for a successful installation. Also, don't forget the BurpSuite Akto extension, which you can download by following the steps from here.

Looking forward to hearing from you. Please let us know if you have any ideas that you would like us to include.

Happy API security testing!

Follow us for more updates

Follow us for more updates

Follow us for more updates

Want to ask something?

Our community offers a network of support and resources. You can ask any question there and will get a reply in 24 hours.

Want to ask something?

Our community offers a network of support and resources. You can ask any question there and will get a reply in 24 hours.

Want to ask something?

Our community offers a network of support and resources. You can ask any question there and will get a reply in 24 hours.

Table of contents