BOLA vs IDOR: Understanding Broken Object-Level Authorization
BOLA (Broken Object Level Authorization) holds the #1 spot on the OWASP API Security Top 10. It occurs when an API endpoint accepts an object identifier (e.g. `/api/v1/invoices/9482`) without validating whether the requesting authenticated session actually owns that resource.
WHAT IS THE DIFFERENCE BETWEEN BOLA AND IDOR?
Historically, IDOR (Insecure Direct Object Reference) referred to web applications displaying sequential database keys (like `user_id=102`) in GET requests or form parameters.
BOLA (Broken Object Level Authorization) expands this concept specifically to REST, GraphQL, and microservice APIs. In modern API architectures, resources are queried directly via unique identifiers (UUIDs or integer IDs) in URL paths or JSON body payloads. When the backend controller fails to execute an access-control verification against the authenticated user token, BOLA occurs.
ANATOMY OF A BOLA VULNERABILITY
Consider an API endpoint that updates user profile settings:
POST /api/v1/users/8841/settings HTTP/1.1
Host: api.targetapp.com
Authorization: Bearer eyJhbGciOiJIUzI1Ni... (Logged in as User 5012)
Content-Type: application/json
{
"email": "attacker@domain.com",
"role": "admin"
}If the server checks that the JWT token is valid for User 5012, but fails to check whether User 5012 is authorized to modify User 8841's record, User 5012 can compromise any account on the platform simply by incrementing or supplying target user IDs.
REMEDIATION & SECURE DESIGN PATTERNS
- Enforce object-level access control checks at every database access boundary.
- Never rely on client-side state or hidden inputs for user identity.
- Use random, unguessable UUIDv4 identifiers for public references.
- Write automated unit & integration tests that attempt cross-tenant access.