API Authorization Testing: Finding BOLA Beyond Obvious IDOR

Contributors

Shantanoo Govilkar
Shantanoo Govilkar
SVP Strategic Solutions Risk & Cybersecurity Solutions

API authorization testing is often reduced to changing an object ID and checking whether another user's record appears. That catches straightforward IDOR vulnerabilities, but modern APIs require a deeper examination.

Broken Object Level Authorization (BOLA) occurs when an API fails to properly determine whether an authenticated user is permitted to access a specific object. The difficult cases are rarely as simple as changing /users/123 to /users/124.

Modern APIs expose nested resources, multiple roles, tenant boundaries, administrative functions, and relationships between objects. An attacker may not need to guess another user's identifier at all. They may manipulate a parent resource, alter a role-dependent parameter, or reuse an identifier obtained legitimately elsewhere.

A penetration test should therefore map authorization relationships, not simply endpoints.

Testers can establish what each role can read, create, modify, and delete, then test those permissions across tenants, object types, workflows, and API versions.

For example, a customer may legitimately access an invoice belonging to their organization. The security question is whether that same customer can modify the invoice, access an internal approval object associated with it, or use the invoice identifier against another endpoint to retrieve another organization's information.

Administrative APIs require similar scrutiny. A normal user may be blocked from an obvious administrative endpoint while another endpoint exposes the same underlying operation through a less obvious route.

This is why API penetration testing needs to examine authorization consistency across the application, rather than simply checking whether authentication works.

A meaningful finding should demonstrate the complete path: the legitimate identity used, the authorization boundary crossed, the affected object, and the resulting business impact.

The objective is not merely to prove that an API contains an IDOR.

It is to determine whether the application's relationship between identity, object, tenant, role, and action holds when someone deliberately tries to break it.

Back
to Top