BOLA (Broken Object Level Authorization)

API Securityadvancedaka IDOR

// Definition

Ranked #1 in the OWASP API Security Top 10. A BOLA (also called IDOR — Insecure Direct Object Reference) vulnerability exists when an API trusts the object ID in the request rather than checking whether the authenticated user is authorised to access that specific resource. Test by replacing `/users/1/orders/100` with `/users/1/orders/101` (an order belonging to a different user) — a vulnerable API returns a 200; a secure one returns a 403 or 404. The fix is server-side authorisation checks on every object access.

// Why it matters

Invisible to happy-path testing — the endpoint works perfectly for its legitimate owner. You only surface BOLA by deliberately crossing user boundaries, so it's a test-design gap, not a tooling one. For any API exposing per-user resources, it's the first authorization test to write.

// How to test

// Authenticate as user A, then request user B's object
cy.request({ url: '/api/users/1/orders/100', headers: tokenA }) // your own
  .its('status').should('eq', 200)

cy.request({
  url: '/api/users/1/orders/101', // belongs to user B
  headers: tokenA,
  failOnStatusCode: false,
}).its('status').should('be.oneOf', [403, 404]) // 200 = vulnerable

// Common mistakes

  • Checking authorization only at login, not on every object access
  • Treating a non-guessable ID (a UUID) as if it were a permission
  • Testing only the happy path, so the bug ships silently

// Related terms