Welcome back to my API pentesting series! In this third blog, we're diving into BOLA (Broken Object Level Authorization) — the #1 API vulnerability on the OWASP list. I'm using crAPI as our testing lab — a free, intentionally vulnerable app that simulates a real car management system. It's ideal for beginners because it's safe, legal, and mirrors how real-world API vulnerabilities actually behave

What is BOLA?

Before jumping into exploitation, let's understand what BOLA actually is.

BOLA (Broken Object Level Authorization) happens when an API does not properly verify whether the logged-in user is actually authorized to access a specific object. In simple words — the server checks if you are logged in, but forgets to check if the data you're requesting actually belongs to you.

For example, if you request /service-report?id=8 and the server returns your report — what happens if you change it to id=9? If it shows someone else's report without any error, that's BOLA.

Step 1: Capturing All Requests from crAPI

Before exploiting anything, the first step is always reconnaissance. We need to understand how the application talks to its backend APIs.

Using Burp Suite, we browse through the entire crAPI application while the proxy intercepts all HTTP traffic in the background.

As you can see in the screenshot, crAPI makes dozens of API calls — using GET, POST, PUT methods — hitting endpoints like /identity/api/, /workshop/api/, /community/api/ and more. This gives us a complete map of all the API endpoints we can test for vulnerabilities.

Method 1: BOLA via Service Report ID (IDOR on URL Parameter)

While browsing crAPI, I navigated to the Contact Mechanic feature and submitted a service request form. I had Burp Suite running in the background intercepting all traffic. As soon as the form was submitted, I caught the POST request in Burp Suite.

Looking at the response, the server returned a 200 OK along with a JSON body that revealed something interesting — a report_link field:

I opened the report_link directly in the browser:

This loaded my own service report — but the sequential numeric ID immediately caught my attention. As a pentester, whenever you see a plain number in a URL, the first instinct is — what happens if I change it?

So I simply changed id=8 to id=9:

And just like that — the server returned another user's complete service report without any authorization check. It exposed their:

• Report ID & Service Status
• Problem Details
• Assigned Mechanic info
• Vehicle VIN number

The API never verified whether this report belonged to the logged-in user. It blindly served whatever ID was requested. Authentication was there — but Authorization was completely missing.

Method 2: BOLA via Vehicle ID

While exploring crAPI, I noticed the Vehicle Details page which shows your car information along with its live location. I had Burp Suite running in the background and caught this API request being made:

The response returned the vehicle's GPS coordinates, owner's full name and email. But what caught my attention was the UUID used to identify the vehicle in the URL. My next thought was — can I use someone else's vehicle UUID and access their location?

Finding the Victim's Vehicle ID

I headed over to the Community section of crAPI where users post about their cars. I interacted with another user's post and intercepted the response in Burp Suite. The response leaked the other user's vehicle UUID in plain text.

Exploiting the Endpoint

I took that UUID and fired a request in Burp Suite Repeater — using my own authentication token but swapping in the victim's vehicle ID:

The server responded with a 200 OK and returned the victim's:

• Real-time GPS coordinates
• Full name & email address

No error. No access denied. Just someone else's live location handed over without any authorization check. Authentication was there — but Authorization was completely missing.

How to Prevent BOLA?

1. Always Enforce Object-Level Authorization Every API endpoint must verify that the authenticated user actually owns the requested object — never trust the ID coming from the request.

2. Never Expose Direct Object References Avoid exposing raw IDs in URLs or API responses. Use indirect references that are mapped server-side to the actual object.

3. Implement a Centralized Authorization Layer Don't write authorization checks separately for every endpoint — apply a centralized access control mechanism consistently across all APIs.

4. Use Unpredictable IDs — But Don't Rely on Them UUIDs make enumeration harder but as we saw in Method 2, they do not prevent BOLA. They are an extra layer, not a fix.

5. Log and Monitor Suspicious Patterns Set up alerts for a single user requesting multiple different object IDs in a short time — a common sign of BOLA exploitation.

Key Takeaway for Beginners: BOLA is not just limited to simple numeric IDs like id=8 or id=9. As you saw in this method, it can also exist in UUID form — those long random-looking strings like 6fe26cd9-e794-4591-b90f-e0be957dfe66. Don't let UUIDs fool you into thinking an endpoint is safe. If the server is not checking who owns the object, the format of the ID doesn't matter. Always test every ID you see in a request — whether it's a number, a UUID, or any other unique identifier. BOLA hides in all shapes and sizes.

Coming Up Next: We covered BOLA in depth today — but the story doesn't end here. In the next blog, we will be diving into BFLA (Broken Function Level Authorization) — another critical API vulnerability where attackers access functions and endpoints they should never have permission to reach. Stay tuned!