Testing UUID Security: Preventing BOLA Exploitation on API Endpoints

This blog is about how to test for BOLA using unauthorized UUID on an API endpoint.

Bola Test Case
Bola Test Case
Bola Test Case
Jaydev Ahire

Jaydev Ahire

5 min read

A UUID (Universal Unique Identifier) is a standardized 128-bit format used to identify information in computer systems. It is often used to identify records or objects within a database or devices or components within a computer system. UUIDs are typically generated using a combination of numbers and letters and are designed to be unique across all devices and systems. 

Attackers can exploit BOLA vulnerabilities by using another user's UUID to access their account or data. This can happen if a system does not properly validate the UUIDs that are used to access user accounts or data or if a system does not properly protect against unauthorized access to UUIDs.

In this article, we will discuss a test case for BOLA, where a vulnerable application fails to authorize a UUID on the API endpoint, allowing us to retrieve another user's information using their UUID.

General Severity: Low to Medium

OWASP Category: API1:2019 Broken Object Level Authorization

For practical demonstration, we will use a completely ridiculous API (crAPI) which is vulnerable by design to test for API vulnerabilities. (Install the vulnerable application by referring to the quick start guide of crAPI)

The vulnerable application has a feature where users can request a refresh location endpoint to view their vehicle's location. The application uses vehicle id to retrieve the location. 

On another side, the application exposes other users' vehicle IDs when replying to their comments.

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.

Test it out with Akto using Akto's BOLA test library.

General reproduction steps:

1.  Once you have installed the application, register and log in to the application.

2. Navigate to the MailHog server on port 8025 to get the vehicle details.

3. Register the vehicle and navigate to the dashboard.

4. At the bottom of the page, Refresh Location while capturing the traffic using Burpsuite (or any other proxy tools). (By the way, you can also create an inventory by importing the captured request in the Akto dashboard using the Burp plugin.)

5. Observe the application was making a request to GET /api/v2/UUID/location endpoint and send a request to a repeater for later use.

6. Now, navigate to the Community tab, and open the comments of any user.

7. Reply to the comment of a user, (In this we have replied to the comment of Title 1, user- Adam.)

8. Navigate to the HTTP history tab in Burpsuite and observe the POST/community/api/comment request.

9. As you can see, the application has exposed the user's details with the vehicle id.

10. Copy the exposed vehicle id and paste it to the previously captured GET/api/v2/UUD/location request. 

11. Send the modified request.

Observe that, by replacing another user’s UUID, we successfully exploited the BOLA vulnerability and allowed us to retrieve another user’s vehicle location information.


Attackers who have access to internal references have direct access to the application's data and state. Attackers can then modify the exposed objects to change data and access confidential information.


Implementing strict access control checks on every functionality to determine whether the user is permitted to access and manipulate the requested object is the best way to prevent BOLA.

  1. Developers implementing the API should implement a robust authorization mechanism. In the above case, the developer should allow access only if the requested uuid is actually owned by the user.

  2. Perform active testing of your endpoints for BOLA vulnerabilities using automated testing products such as Akto. Do not deploy vulnerable changes that break the tests.

Besides, IDs and UUID attackers can manipulate weak authorization tokens to perform BOLA attack. We will see that in the next blog.

Here is a list of all BOLA tests in Akto. We are adding more tests every week to make BOLA testing comprehensive:

  1. IDOR by adding user id in query params

  2. BOLA by changing auth token

  3. BOLA in old api versions

  4. BOLA by HTTP Parameter Pollution

If you want us to add a case you don't see above, write to us at

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