Same vulnerability, different names. Here's why both exist and when to use which term.
| IDOR | BOLA | |
|---|---|---|
| Full name | Insecure Direct Object Reference | Broken Object Level Authorization |
| Origin | OWASP Web Top 10 (since 2007) | OWASP API Security Top 10 (2019) |
| Context | Web applications | APIs |
| Mechanism | Change an ID in a URL or form parameter | Change an object ID in an API request |
| Root cause | Same: missing authorization check on the object | Same: missing authorization check on the object |
| Ranking | Part of A01: Broken Access Control | #1 on OWASP API Security Top 10 |
| Testing | Swap IDs in browser requests | Swap IDs in API calls with different auth tokens |
IDOR and BOLA describe the exact same vulnerability: an application lets you access an object (file, record, account) by providing its identifier, without checking that you're authorized to access it.
The terminology split happened because OWASP created a separate API Security Top 10 in 2019. In the web world, we'd been calling it IDOR since 2007. The API folks renamed it BOLA to fit the API-specific context. Same bug, different audience.
If you're writing a bug bounty report for a web application, say IDOR — everyone knows what it means. If you're discussing API security or referencing the OWASP API Top 10, say BOLA. In a pentest report, I'd use whichever matches the context, but I'd define it either way since not everyone tracks the terminology.
Authorization checks are custom per endpoint. There's no framework middleware that automatically knows "user A owns object 5." Developers have to write that check every time, and they forget. Multiply that across hundreds of endpoints and you see why BOLA/IDOR accounts for 40% of all API attacks.