Deepshikha Paty
DI-ASM
What is BOLA (Broken Object Level Authorization)?
BOLA happens when an API lets users access data just by changing the object ID in the request — without checking if they’re authorized to do so.
For example:
If a user changes /user/1 to /user/2 in the API link and gets someone else’s data — that’s BOLA!
Example 1:
Example
Filename-Based BOLA Example:
- A user accesses their payslip by opening:
https://company.com/payslips/deepshikha_march2025.pdf - Out of curiosity, they modify the URL to:
https://company.com/payslips/rahul_march2025.pdf - The system serves Rahul’s payslip without checking if the logged-in user is allowed to access it.
✅ Broken object-level authorization: the filename is an object identifier that’s not access-controlled.
Example 2:
Example
Token-Based BOLA Example:
- A user resets their password using a recovery link:
https://example.com/reset-password?token=abc123 - They tamper with the token to:
https://example.com/reset-password?token=def456 - If the system doesn't validate whether the token belongs to the currently authenticated user, they might reset another user’s password.
✅ Object is the token, and authorization is missing = BOLA.
Example 3:
Example
Invoice/Order Number Format Example:
- A logged-in customer accesses their invoice:
https://shop.com/invoices/INV_2025_A001 - They modify the URL to:
https://shop.com/invoices/INV_2025_A002 - If the system doesn’t validate the customer’s ownership of the invoice, they gain access to another person’s invoice.
✅ Object = invoice number, not an ID, but still sensitive.
🎯 Why is it a problem?
If there’s no security check, anyone can access private data just by changing the ID in the request.
This can lead to:
- Personal data leaks
Account takeovers- Huge damage to a company’s trust and finances
✅ How to Prevent ?
- Always check if the user is allowed to access the data.
- Use access tokens to identify who is making the request.
- Use random or encrypted IDs so they can’t be guessed.