Here's one of the most common serious vulnerabilities found in modern applications — and the easiest to explain to a non-technical person.
Imagine your own invoice page opens at yourpartner.com/invoices/1042. Simple enough: logging in shows your invoice, you pay it, done. But what happens if you change the number to 1043? If the page happily shows another customer's invoice — their name, their amount, their payment details — that's an IDOR.
What IDOR actually means
IDOR stands for Insecure Direct Object Reference. In plain words: an application uses predictable identifiers (IDs, usernames, file names) to fetch data, but never checks whether you're allowed to access that specific object. The ID in the URL is the authorization — and that's not authorization at all.
In modern API-based systems it's often called BOLA (Broken Object Level Authorization) — the same flaw wearing an API costume. The API returns "the record with this ID" without asking whose record it is.
Why is it so common?
- Developers trust the ID and forget the permission check — it's one missing line, easy to miss.
- Authentication says "you're logged in", but that's not the same as "you may see this record".
- Hidden menu items and unguessable-looking IDs give a false sense of safety.
- Each new endpoint is a new place to forget the check.
Why you should care
This is a data-leak vulnerability: one broken link is all it takes for one customer (or attacker) to walk through another customer's data — invoices, orders, messages, personal records. In a business-to-business context the stakes are higher still, because your partners trust you with their data too. It's exactly the kind of finding that ends up on a breach report before a fix lands.
How it's tested responsibly
In an authorized engagement, this is verified like this: within the agreed scope, I test whether object-level access is enforced — and prove impact without handling real customer data. Two test accounts, permission checks across roles, and evidence that shows the authorization flaw without ever exposing production data. The report then shows you precisely which endpoints are affected and how to fix them.
How it's fixed
- Object-level authorization on every endpoint — before returning a record, verify the current user is permitted to access exactly that record.
- Treat "user A can see user B's data" as a critical defect, not a cosmetic one.
- Test authorization across roles, not just "logged in vs not logged in".
This class of flaw is the heart of API security testing, and it routinely turns up in web applications too. If your app or API has never been checked for it, it belongs on your list.