Bypassing Broken Object Level Authorization (BOLA) in Modern APIs

Introduction

Broken Object Level Authorization (BOLA), also known as Insecure Direct Object Reference (IDOR), remains the #1 API vulnerability on the OWASP API Security Top 10. Despite its simplicity, it continues to plague even the most mature engineering organizations.

What Is BOLA?

At its core, BOLA occurs when an API endpoint exposes an internal object identifier — such as a database ID, UUID, or sequential number — and fails to validate whether the requesting user is authorized to access the referenced resource.

Consider a typical REST endpoint:

GET /api/v1/users/1042/invoices
Authorization: Bearer <token_for_user_1041>

If the server returns invoices for user 1042 without checking the token's ownership, BOLA exists.

Why Automation Fails Here

Automated scanners typically send malformed or boundary-value inputs. They rarely test authorization context — swapping one valid user's token for another's. This is fundamentally a logic flaw, not a syntax error.

Manual Exploitation Techniques

1. Sequential ID Enumeration

The simplest approach: increment or decrement numeric IDs in the URL path or query parameters while authenticated as a different user.

# Authenticated as user A, requesting user B's data
curl -H "Authorization: Bearer $TOKEN_A" \
  https://api.target.com/v1/orders/50124

2. UUID Harvesting

When UUIDs are used, attackers harvest them from other endpoints — search results, public profiles, email notifications, or even client-side JavaScript bundles.

3. Parameter Pollution

Some frameworks allow duplicate parameters. Sending ?user_id=1041&user_id=1042 may cause the backend to process the second value while middleware validates the first.

4. GraphQL Nested Queries

In GraphQL APIs, BOLA often hides in nested resolvers. A user might be authorized to query their own profile but can traverse relationships to access other users' data:

query {
  me {
    organization {
      members {
        invoices { amount, description }
      }
    }
  }
}

Real-World Impact

In our assessments, we've found BOLA vulnerabilities that exposed: - Medical records of 2M+ patients through a healthcare API - Financial transactions across a fintech platform's entire user base - Private documents in a SaaS collaboration tool used by Fortune 500 companies

Remediation

1. Implement object-level authorization checks on every data-access operation — not just at the controller level, but at the data layer.
2. Use indirect references — map internal IDs to per-session tokens that cannot be guessed.
3. Log and alert on cross-user access patterns. If user A is requesting resources belonging to users B, C, and D in rapid succession, that's a red flag.
4. Adopt policy-as-code frameworks (like OPA or Casbin) to centralize authorization logic.

Conclusion

BOLA is deceptively simple, but its impact is catastrophic. No scanner will reliably catch it because it requires understanding your application's authorization model. This is why manual API penetration testing isn't optional — it's essential.