Back to blog
APIIDORBOLA

BOLA and IDOR: why your API exposes other customers' data

Published on 2026-04-057 min readFlorian

BOLA and IDOR, are they the same thing?

Nearly. IDOR (Insecure Direct Object Reference) is the legacy term. BOLA (Broken Object Level Authorization) is the term used by the OWASP API Security Top 10 since 2019. The concept is identical: an authenticated user accesses another user's resources by manipulating the resource identifier in the request.

Why it's so common

Web frameworks make it easy to create CRUD routes. A developer creates GET /api/documents/:id and the controller fetches the document by ID. But verifying that the logged-in user is authorized to view that document is a manual step. No framework adds it automatically. You have to explicitly write if (document.userId !== currentUser.id) return 403.

Aggravating factor: sequential identifiers. If IDs are 1, 2, 3, 4..., the attacker can enumerate them all. UUIDs reduce the enumeration risk but don't replace authorization checks.

Exploitation techniques

Direct enumeration

The attacker iterates through a range of IDs: GET /api/users/1, GET /api/users/2, and so on. With an automated script, thousands of profiles are extracted in minutes.

Parameter manipulation

Changing user_id in the body of a POST or PATCH request. If POST /api/transfer accepts {"from_account": "attacker", "to_account": "victim", "amount": 1000} without verifying the caller owns the source account, that's a critical BOLA.

GraphQL and nested queries

In GraphQL, an attacker can navigate relationships: query { user(id: 42) { documents { content } } }. If the User type resolver doesn't check authorization, any user's documents are accessible.

Via files and media

Download URLs with predictable IDs: /api/files/invoice_1042.pdf. The attacker changes the invoice number to access other customers' documents.

Defenses

  • Systematic checks: every endpoint must verify that the logged-in user owns or has rights to the requested resource. No exceptions.
  • Authorization middleware: centralize the logic in middleware rather than in each controller. A single oversight in one controller is enough to create a flaw.
  • Row Level Security: on Supabase and PostgreSQL, RLS policies check authorization directly at the database level. Even if the application code misses a check, the database blocks access.
  • Unpredictable identifiers: use UUID v4 instead of sequential integers. This doesn't eliminate the risk but makes enumeration impractical.
  • Automated authorization tests: for each endpoint, write a test that verifies user B cannot access user A's resources.
  • Real impact

    BOLA enables mass exfiltration of personal data. Under GDPR, that's a data breach requiring notification to the supervisory authority within 72 hours. At CleanIssue, we identify BOLA in roughly 40% of the APIs we audit. Request your audit call.

    Related articles

    Three adjacent analyses to keep exploring the same attack surface.

    Sources

    Written by Florian
    Reviewed on 2026-04-05

    Editorial analysis based on official vendor, project, and regulator documentation.

    Related services

    If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.

    Need an external review of your HR SaaS?

    Share your product, stack, and client context. We will come back with the right review scope.

    Discuss your audit