FREE NOTES API-HACKING DAY2 : Introduction And Understanding About BOLA Bug

Welcome back, HackingBlogs readers and fellow API security enthusiasts!

Day 2 of our API hacking course begins today, digging deeply into Broken Object Level Authorization (BOLA), one of the most important and frequently abused vulnerabilities. We’ll go over what BOLA is, why it’s a major risk to APIs, and how attackers usually take advantage of it in the wild in this session.

Additionally, we’ll show how to use Burp Suite and the purposefully flawy crAPI (completely ridiculous API) to intercept, examine, and alter request-response flows.

Therefore, let’s get started straight away and learn how to find BOLA problems efficiently.

Tools You’ll Be Needing

You must set up a few necessary tools in order to follow along and practice API hacking, particularly focusing on BOLA vulnerabilities:

Docker Desktop
For safe, local testing, we will use Docker to run crAPI (totally ridiculous API) in a containerized environment. You can consult your operating system’s official documentation here if you haven’t installed Docker yet.

The Burp Suite
Our preferred tool for intercepting, examining, and modifying API requests and answers will be Burp Suite. This lab works well with the Community Edition, but if you have access, the Professional version enables greater automation.

A live crAPI instance is an alternative.
I will also be using the publically hosted version of crAPI at http://crapi.apisec.ai/login if you are unable to set up Docker locally.
⚠️ Note: Because it’s a shared public instance, it frequently receives a lot of traffic, thus occasionally answers could be sluggish or irregular.

Before moving on to the exploitation section, make sure everything is setup and functioning properly. When you’re prepared, let’s proceed to comprehending the practical use of BOLA.

Understanding About The BOLA Bug : BROKEN OBJECT LEVEL AUTHENTICATION

What is a BOLA Bug?

One of the most dangerous and frequently discovered flaws in modern APIs is BOLA (Broken Object Level Authorization). Yes, they are basically the same thing, especially when it comes to APIs. You may have also heard it called IDOR (Insecure Direct Object Reference).

Here’s the main concept: In order to retrieve certain data, APIs frequently include unique identifiers (such as user IDs, roll numbers, account numbers, etc.) in the request. For instance:

GET /api/user/rollno/1045 → returns your personal details  
GET /api/user/rollno/1046 → returns another user’s details

Attackers can easily alter the identifier (such as the roll number or user ID) in the request and, suddenly obtain unauthorized access to someone else’s data if the server fails to appropriately confirm whether the requesting user is permitted to access the resource associated with that ID.

BOLA specifically takes advantage of this weakness in object-level access control.

Exploiting Bola Bug Using OWASP crAPI ?

General Approach to Testing API Endpoints for BOLA

Analyzing how multiple endpoints react, particularly after engaging with different application features, is a clever method to spot any BOLA concerns while working with a vulnerable API like crAPI.

Here’s a useful hint: Look for endpoints that display a checkmark (✔️) in the developer tools of the browser or in Burp Suite.

This often means that a parameterized POST request was issued and handled correctly. These endpoints are more likely to be associated with user identifiers such as userId, accountId, vehicleId, etc. and frequently handle user-specific data.

Finding the Endpoint That Is Vulnerable: Go to HTTP history in Burp Suite and search for the following endpoint to start exploiting BOLA in crAPI:

/workshop/api/merchant/contact_mechanic

The workshop module includes this particular API request, which is normally initiated when a mechanic is contacted via the application. It is a good candidate for BOLA testing because it is a POST request that transmits data with an object identifier.

Once this request has been located in the history, intercept it and carefully examine the parameters. Now that you have the object-level identifiers in that request manipulated, you can start the real exploitation.

When the endpoint’s response is intercepted:

POST /workshop/api/merchant/contact_mechanic

you’ll see a strange response from the server. It contains a hidden URL that leads to a mechanic report in addition to a status confirmation:

"report_link": "http://crapi.apisec.ai/workshop/api/mechanic/mechanic_report?report_id=6217"

This URL is returned in the JSON response but is not immediately apparent in the application’s user interface. It reveals a parameter called report_id, a traditional object-level access indication that is ideal for BOLA exploitation.

Testing for BOLA via Direct ID Manipulation

Let’s try something simple yet powerful:

1. Copy the report_link URL from the response.
2. Paste it into your browser or send a new request in Burp Suite.
3. Now, manually change the report_id in the URL — for example, try 6216, 6215, or any other value.

Example:

Now Let’s Change The ID Values . On changing the ID from 6217 to 6210 we get http://crapi.apisec.ai/workshop/api/mechanic/mechanic_report?report_id=6210

The API returns extremely sensitive information belonging to another user without any kind of access control or validation after changing the report_id argument and gaining access to a different mechanic report.

This demonstrates that there is a significant BOLA vulnerability. An attacker can obtain the personal and vehicle-related data of another user by only altering an ID value in the URL (report_id=6210). In addition to being against data privacy standards, this kind of exposure may result in identity theft, targeted social engineering assaults, or more exploitation.