Introduction

Broken Object Level Authorization (BOLA) is ranked API1:2023 in the OWASP API Security Top 10 — and for good reason.

It's one of the most common and most damaging API vulnerabilities today.

At its core, BOLA happens when an API does not properly verify whether a user is allowed to access a specific resource. The user may be authenticated, but authorization is missing or incomplete.

When that happens, attackers don't need fancy exploits — they just change IDs.

What BOLA Really Is (Plain Language)

APIs work with objects: users, orders, invoices, messages, accounts, etc. Each object is identified by some form of ID — numbers, UUIDs, strings, usernames.

If an API trusts the ID sent by the client without verifying ownership, BOLA exists.

Authentication answers: Who are you? Authorization answers: Should you access this?

BOLA is what happens when the second question is skipped.

A Simple Example

Imagine an API endpoint like this:

GET /api/v1/accounts?id=1021

If a logged-in user sends this request and receives their own account details, that's expected.

But if the same user changes the ID:

GET /api/v1/accounts?id=1022

…and the API returns another user's data, then the API is vulnerable.

No hacking. No bypass. Just trusting user input.

Why BOLA Is So Common

BOLA isn't common because developers are careless — it's common because modern APIs are complex.

Some reasons it keeps showing up:

  • APIs rely heavily on client-side state
  • Many endpoints accept object IDs directly
  • Authorization logic is scattered across services
  • Developers forget to apply checks consistently
  • Automated scanners struggle to detect authorization flaws

Even teams with a solid authorization system still introduce BOLA when new endpoints skip the check.

How Attackers Exploit BOLA

Attackers look for endpoints that accept object IDs and ask simple questions:

  • Does this ID belong to me?
  • What happens if I change it?
  • Does the response change?
  • Can I enumerate multiple IDs?

They don't guess randomly — they observe patterns.

If one object ID works, others often will too.

The Real Impact

BOLA vulnerabilities can lead to:

  • Exposure of sensitive personal data
  • Modification or deletion of other users' records
  • Privilege escalation
  • Full account takeover in some cases

This is why BOLA is considered high impact, low effort.

How Developers Should Think About Fixing BOLA

The fix is rarely complicated — but it must be intentional.

1. Centralize Authorization Decisions

Every access decision should answer questions like:

  • Can this user view this record?
  • Can this user modify this resource?
  • Does this role allow this action?

Authorization logic should live in one place — not scattered across controllers.

2. Enforce Authorization Everywhere

A strong authorization system is useless if it's not called.

Every endpoint that:

  • accepts an object ID
  • queries the database
  • modifies a resource

must enforce authorization before access.

3. Don't Trust IDs from the Client

IDs are not the problem — trusting them is.

Using UUIDs instead of numbers helps slightly, but it does not solve BOLA.

Authorization must always verify ownership or permission.

4. Test for Authorization Failures

Authorization bugs don't always break functionality — they break security.

Tests should explicitly check that:

  • users cannot access other users' data
  • roles are enforced correctly
  • edge cases don't bypass checks

Summary

Broken Object Level Authorization happens when APIs trust object IDs without verifying access rights.

It's easy to miss, easy to exploit, and extremely damaging.

BOLA isn't about clever attackers — it's about missing authorization checks.

Fixing it requires discipline, not complexity.