API Security · intermediate · ~11 min
Test for BOLA — the API's #1 risk — and state the fix.
BOLA (API Top 10 #1) is IDOR for APIs: an endpoint trusts an object ID without checking ownership, so swapping IDs returns other users' data. Test by replaying user A's object requests as user B. Fix: per-object server-side authorization on every access; opaque IDs are not a substitute.
BOLA is the most common and damaging API vulnerability — bulk data exposure from a single altered ID, no exploit chain required. Testing every object reference across users is the highest-yield API activity.
BOLA = API IDOR. Object ID trusted without ownership check. ID locations. Path, query, body, headers. Test. Replay A's requests as B / unauthenticated. Root cause. AuthN checked, per-object authZ missing. Fix. Mandatory per-object server-side check; opaque IDs ≠ control.
BOLA (OWASP API #1) is IDOR at API scale: the endpoint accepts an object ID and returns/acts on it without verifying the caller owns it.
GET /api/v1/accounts/5001/statements ← your account
GET /api/v1/accounts/5002/statements ← someone else's — returned
Object IDs appear in paths, query params, JSON bodies, and headers. Because APIs are object-centric, BOLA is both the most common and most impactful API bug — it's mass data exposure with a single altered identifier.
Developers check authentication (valid token) but forget per-object authorization. A valid token says who you are, not which records you may see.
On every object access, verify the authenticated principal is authorized for that specific object — server-side, deny by default. Random/opaque IDs help but are not a control (UUIDs leak); the authorization check is mandatory.
BOLA is the top API risk: missing per-object authorization lets attackers reach other users' data by changing an ID. Find it by cross-user replay; fix it with a mandatory server-side ownership check on every object access.