OWASP API Security Top 10 has listed Broken Object Level Authorization (BOLA) as the number one API security risk since 2019. In 2025 it remained at number one. BOLA and its sibling, Broken Function Level Authorization (BFLA), are responsible for the majority of significant API data breaches — Optus, T-Mobile, Peloton, and dozens of smaller incidents all share the same root cause.
What BOLA Is
BOLA occurs when an API endpoint performs an action on an object identified by a user-supplied ID without verifying that the requesting user has access to that specific object. The pattern is GET /api/orders/1234 where 1234 is an order ID. If the API returns order 1234 regardless of whether the authenticated user owns order 1234, that is BOLA.
The fix seems obvious: check ownership before returning data. The reason BOLA persists is that it is structural — it requires every endpoint that accepts an object ID to implement the check. When a codebase has hundreds of endpoints and the check is implemented per-endpoint rather than at a middleware layer, it gets missed.
What BFLA Is
BFLA occurs when an API endpoint performs a privileged function that the requesting user should not have access to, but the authorization check is missing or bypassable. Unlike BOLA (which is about data access), BFLA is about actions. DELETE /api/users/:id is a function that should only be callable by admins — if a regular user can call it successfully, that is BFLA.
The Testing Gap
Standard test suites check that the right user can access their own data. They rarely check that the wrong user cannot access someone else's data. Comprehensive BOLA testing requires generating two accounts, creating data as account A, and verifying that account B cannot access it across every data-returning endpoint. This is tedious to automate and commonly skipped.
G8KEPR schema validation catches some BOLA patterns by flagging responses that include object IDs not associated with the requesting organization. This is not a substitute for proper authorization code, but it catches leakage at the response layer as a safety net.
Related reading
Row-Level Security for Multi-Tenant APIs: Implementation Patterns
The database-layer complement to API authorization — how RLS prevents BOLA at the data layer so the API layer is never the only gatekeeper.
Related reading
Shadow API Discovery: Finding the Endpoints You Forgot You Had
BOLA is especially dangerous on shadow endpoints where authorization was never implemented. Find them before attackers do.
Catch authorization failures at the gateway
G8KEPR validates response schemas and cross-org object ID leakage in real time — acting as a safety net when application-layer authorization has gaps.
Start free trial