Insecure direct object reference (IDOR)
IDOR · BOLA · broken object level authorization · broken access control · authorisation bypass
An access control flaw in which an application serves a resource (an invoice, a file, an account) based on its identifier alone, without checking that the user is entitled to see it.
In practice
If the address of your invoice ends in a number, what happens when you change that number? In a vulnerable application, you see another customer’s invoice. The flaw is simple, often hard to detect automatically (a tool does not know what each user is allowed to see) and can be exploited at scale with a script. It falls under Broken Access Control, the number one risk in the OWASP Top 10:2025 (A01), and is called BOLA in the OWASP API Security Top 10.
In July 2023, the Australian and US cybersecurity agencies (ACSC, CISA, NSA) issued a joint advisory on IDOR flaws, describing them as common, hard to prevent outside the development process and already responsible for breaches affecting millions of users.
How to protect yourself
- Check on the server, for every request, that the user is entitled to the object requested.
- Centralise authorisation rules instead of repeating them page by page.
- Prefer random identifiers (UUIDs) to sequential numbers, as an extra layer on top of proper checks.
- Always test with two different user accounts during acceptance and penetration testing.
