Broken Object Level Authorization (BOLA) Vulnerabilities in crAPI

One of the most critical vulnerabilities in API security is Broken Object Level Authorization (BOLA). It is ranked as API1: Broken Object Level Authorization in the OWASP API Security Top 10, making it one of the most common and dangerous API vulnerabilities.

What is BOLA?

Broken Object Level Authorization occurs when an API fails to properly verify whether a user has permission to access a specific object or resource. APIs frequently expose endpoints that reference objects using identifiers such as:

• User IDs
• Account numbers
• Order IDs
• Transaction IDs

If the backend does not validate whether the authenticated user actually owns or is authorized to access the requested object, an attacker can simply modify the object identifier and retrieve data belonging to another user.

Learning BOLA Using crAPI

To understand how BOLA works in practice, we will use two intentionally vulnerable API environments:

• crAPI

Both environments contain multiple API vulnerabilities aligned with the OWASP API Security Top 10, including BOLA.

Practical

1. Access details of another user’s vehicle (crAPI):

• Login, sign up and add vehicle details
• Refresh the location and intercept the request in Burp suite. Notice that it reveals an API endpoint that requires a vehicle ID.

• On visiting the community tab and intercepting his request, it reveals the vehicle ID and other details associated with another user who have posted in the community.

• After getting the Vehicle id of another user we can successfully gained access to the location details of their vehicle.

2. Accessing another users’ mechanic details:

• In the dashboard tab there is feature called contact mechanic where we can contact the mechanic regarding our vehicle.
• On filling the form and intercepting the request in Burp suite, we can observe in the response that there is a suspicious parameter called ‘report_id’. This indicate that a report with a report id associated with it is generated for each contact to mechanic.

• On the service history page we can observe that our service report has been generated now intercepting this request in burp suite and changing the ‘report_id’ value , we can successfully gain details of another users mechanic report.

3. Accessing other users’s order details:

• In shop tab we can shop for various vehicle accessories.
• Upon placing the order and checking the order details, we can notice that the url endpoint contain contains ‘order_id’.

• Upon intercepting this response, we can get our order details for ‘order_id=6’. Notice that it fetches very interesting data which discloses data like order number, email-id, phone number, amount-paid, card details (last 4 digits) etc. Which is sensitive information.

• On brute forcing, we can get the order details of another user, hence we can successfully access personal information like the card number, card type, card expiration, transaction id.

Conclusion

In this article, we explored the concept of BOLA and understood how attackers can manipulate object identifiers to access resources belonging to other users. By using intentionally vulnerable environments like crAPI, we demonstrated how such vulnerabilities can be identified and analyzed during API security testing.

Stay tuned for the next part, where we will explore more API vulnerabilities and their exploitation techniques in VAmPI and crAPI.