Broken Object Level Authorization (BOLA), also classified as Insecure Direct Object Reference (IDOR), is the single most prevalent vulnerability in contemporary API architectures. It occurs whenever an API endpoint accepts an object identifier directly from a client request and accesses that object in the database without checking whether the requesting user is authorized to perform that action.
How BOLA manifests in code
Consider a common endpoint pattern: `GET /api/v1/invoices/:id`. In a vulnerable implementation, the backend queries the database using only the provided ID parameter:
Vulnerable query: `SELECT * FROM invoices WHERE id = :id`. Notice that this query completely ignores the authenticated user's organization or user ID. If user 102 changes the ID in the request from 500 to 501, the database happily returns customer 501's sensitive billing data.
The myth that UUIDs eliminate BOLA
Many engineering teams believe that replacing auto-incrementing integers with random UUIDs resolves the issue. This is a dangerous misconception. UUIDs make identifiers difficult to enumerate sequentially, but they do not enforce authorization. If an attacker discovers an identifier through logs, search engines, error messages, or shared links, the API remains completely exploitable.
Obscurity of an identifier is not an access control mechanism. Every database query that accesses customer data must include the authenticated tenant or user context in its WHERE clause.
Remediation patterns for modern APIs
- Scoped queries: `SELECT * FROM invoices WHERE id = :id AND org_id = :current_user_org_id`.
- Policy-based authorization: enforce centralized authorization middleware or libraries (such as Casbin, Oso, or Cerbos) before executing queries.
- Automated paired-account testing: use BugSnaps MyPentest to automatically test records created by Account A against the session of Account B.