IDOR and BOLA

Why It Matters

IDOR and BOLA represent the single most impactful class of API vulnerability. Broken Object Level Authorization has occupied the number one position on the OWASP API Security Top 10 since its inception in 2019 and retained that position in the 2023 update.

The reason is simple: APIs expose object identifiers in URLs, request bodies, and query parameters. If the server does not verify that the requesting user owns or has permission to access the referenced object, any authenticated user can access any other user's data by manipulating those identifiers.

Real-world BOLA vulnerabilities have exposed millions of user records across platforms ranging from financial services to social media. The vulnerability is particularly dangerous because:

• It requires no special tools or skills to exploit
• A single vulnerability can expose every user's data
• It often bypasses encryption since the attacker is authenticated
• Automated exploitation can harvest entire databases

For penetration testers and bug bounty hunters, BOLA/IDOR testing is one of the first skills to master because it yields the highest number of valid findings relative to effort.

How IDOR and BOLA Work

The Basic Pattern

An application assigns identifiers to objects: user profiles, orders, invoices, files, messages, or any other resource. When a user requests an object, the API receives the identifier and returns the corresponding data. The vulnerability exists when the API checks authentication (is this user logged in?) but skips authorization (does this user have permission to access this specific object?).

Common Identifier Types

• Sequential numeric IDs: /api/users/1001 through /api/users/9999. Easy to enumerate.
• UUIDs: /api/orders/a3f8e2c1-.... Harder to guess but not impossible if leaked in other responses.
• Encoded values: Base64 or hashed identifiers that can sometimes be decoded or predicted.
• Composite keys: /api/org/5/user/12. Multiple identifiers that each need authorization checks.

Testing Methodology

1. Create two accounts with different roles or ownership
2. Capture all API requests that contain object identifiers
3. Swap identifiers between accounts
4. Test across all HTTP methods (GET for reading, PUT/PATCH for updating, DELETE for removing)
5. Check both the response status code and the response body

Prevention

The fix requires server-side authorization checks on every request that accesses a user-specific resource. The server must verify that the authenticated user has permission to access the specific object referenced in the request, not just that a valid authentication token is present.

• Implement object-level permission checks in API middleware or at the data access layer
• Never rely on obscurity (UUIDs) as a substitute for authorization
• Use indirect references where possible (map session-specific tokens to actual database IDs server-side)
• Log all access patterns and alert on horizontal access across user boundaries