Overview
The single most common API vulnerability is broken object-level authorization — failing to check that the caller may access the specific object they request. This lesson focuses on it in the API context.
Learning objectives
- Define broken object-level authorization (BOLA/IDOR) for APIs.
- Explain why APIs are especially prone to it.
- Describe the required per-object authorization check.
Core concept
Object-level authorization verifies that the authenticated caller is permitted to access the particular object referenced in a request (by ID/key). Its failure — BOLA (Broken Object Level Authorization), also known as IDOR — lets a caller access other users' objects by changing an identifier. APIs are especially prone to this because they expose many endpoints that reference objects directly by identifiers, and developers often check only that the caller is authenticated, not that they own the requested object.
How it works
An API endpoint like GET /api/accounts/{id}/transactions must confirm the authenticated caller is authorized for that account — not merely that they are logged in. If it retrieves data based solely on the {id} in the request, an attacker can iterate identifiers to read others' objects. The required control is a per-object authorization check: for every object-referencing request, verify ownership or permission on that specific object, and deny otherwise. Unpredictable IDs (UUIDs) raise the bar but do not replace the check — obscurity is not authorization.
Practical example
A user calls GET /api/invoices/1001 and receives their invoice. Changing to 1002 returns another customer's invoice because the endpoint never verifies the caller owns invoice 1002 — a classic BOLA/IDOR. The fix: before returning invoice {id}, confirm it belongs to (or is permitted for) the authenticated caller, returning 403/404 otherwise. Because APIs expose many such object-referencing endpoints, this check must be applied consistently across all of them.
Cybersecurity relevance
BOLA is consistently ranked the top API security risk because it is widespread and high-impact — it can expose or modify large amounts of other users' data simply by iterating identifiers, often automatable at scale. It is the API-context form of the object-level-authorization flaw from the authorization module. Testers systematically change identifiers to reach objects they should not; defenders enforce per-object ownership/permission checks on every object-referencing endpoint, treating authentication and object authorization as distinct requirements.
Common mistakes
- Checking only authentication ("is the caller logged in?") not object authorization ("may they access this object?").
- Relying on unpredictable IDs as the sole defense — obscurity is not authorization.
- Applying the check on some endpoints but not others that reference the same objects.
Key takeaways
- Object-level authorization verifies the caller may access the specific object referenced; its failure is BOLA/IDOR.
- APIs are especially prone because they expose many object-referencing endpoints and often check only authentication.
- Enforce a per-object ownership/permission check on every object-referencing request (unpredictable IDs help but don't replace it); BOLA is the top API risk.
Check your understanding
- Why are APIs particularly susceptible to broken object-level authorization?
- What check must an object-referencing API endpoint perform beyond confirming the caller is authenticated?