OWASP API Security Top 10 Highlight — 1. BOLA (Broken Object Level Authorization)

🚨 OWASP API Security Top 10 Highlight — 1. BOLA (Broken Object Level Authorization)

Let’s Understand BOLA (Broken Object Level Authorization) .
BOLA occurs when an API doesn’t enforce proper access control, meaning the server isn’t checking whether the user requesting a resource actually owns that resource.

Real Example:
User Bruce makes this request:
GET https://herohospital.com/api/v3/users?id=2727

Response:
{
"id": "2727",
"fname": "Bruce",
"lname": "Wayne",
"diagnosis": "Depression"
}

Perfect — Bruce is allowed to access his own data.
But if Bruce simply changes the ID:
GET https://herohospital.com/api/v3/users?id=2728
And he gets Harvey’s data 👀
{
"id": "2728",
"fname": "Harvey",
"lname": "Dent",
"diagnosis": "DID"
}

🚨 Boom. That’s BOLA.
It means one user can access another user’s private data — which should never happen.

Why Does This Happen?
Because the API blindly trusts the id, username, or resource identifier provided by the client — without verifying ownership on the server side.
Where BOLA Commonly Hides 👀

Try noticing the bold parts:
GET /api/user/**1**
GET /user/account/find?user_id=**aE1230000token**
POST /company/account/**Apple**/balance
GET /admin/settings/account/**bman**

If these values are predictable or guessable, attackers can try swapping them.
For example:
/api/user/3
/user/account/find?user_id=23
/company/account/Google/balance
/admin/settings/account/hdent

If you get real data back → BOLA confirmed.
How to Fix BOLA (Simple + Practical)
✅ Always perform server-side ownership validation
✅ Ensure resource belongs to the authenticated user
✅ Use OAuth scopes / RBAC / claims
✅ Prefer non-sequential, non-guessable IDs (UUIDs)
✅ Log suspicious enumeration attempts & rate-limit requests
In Short:
If changing just one ID reveals someone else’s data → BOLA is present.