What Is an IDOR Vulnerability and Why Is It So Dangerous?

What is an IDOR vulnerability and why is it so dangerous?

IDOR — Insecure Direct Object Reference — consistently appears in lists of the most critical web application vulnerabilities. It has been responsible for some of the largest data breaches of the past decade, exposing millions of customer records with attacks that required no sophisticated tools — just a browser and the ability to change a number in a URL.

What IDOR actually means

Most web applications use identifiers to reference objects — database records, user accounts, orders, invoices, files. A typical URL might look like this: yoursite.com/orders/12345. The number 12345 is a direct reference to a specific order in the database.

An IDOR vulnerability exists when the application retrieves that order without checking whether the person requesting it is actually allowed to see it. An attacker simply changes 12345 to 12346, 12347, and so on — and if the application does not verify ownership, they can access every other customer's orders.

The attack requires no technical skill. No malware. No exploit code. Just changing a number.

Why IDOR is particularly dangerous

The damage from IDOR is immediate and often massive. Unlike many vulnerabilities that require chaining with other issues, IDOR directly exposes real data to anyone who looks for it.

In e-commerce applications, IDOR vulnerabilities can expose order histories, delivery addresses, and payment method details for every customer. In healthcare applications, patient records. In financial applications, account balances and transaction histories. In any application with user accounts, the personal information of every registered user.

The Uber breach in 2016 involved an IDOR vulnerability that allowed access to driver and passenger data. The Facebook breach exposing 540 million records in 2019 included IDOR components. Closer to home, the NHS has experienced IDOR vulnerabilities in patient-facing systems that exposed appointment and medical information.

How to spot IDOR in your own application

Look for URLs and API requests that contain numbers or identifiers that reference specific records. Common patterns include:

- /orders/12345 - /invoice?id=67890 - /user/profile/111 - /api/v1/customers/42

If your application uses sequential numeric IDs and does not verify that the logged-in user owns the object being requested, you likely have an IDOR vulnerability.

The test is straightforward: log in as one user, find a URL containing your user or order ID, log in as a different user in another browser, and try to access the first user's URL. If it works — if you can see the first user's data while logged in as the second user — the vulnerability exists.

The business impact

Under UK GDPR, an IDOR vulnerability that allows unauthorised access to personal data constitutes a personal data breach. If exploited, you have 72 hours to report it to the ICO. Fines for IDOR-related breaches have reached hundreds of thousands of pounds for UK businesses — not because the vulnerability was sophisticated, but because it was preventable and the data exposed was significant.

Beyond regulatory consequences, the reputational damage from customers discovering their data was accessible to anyone who changed a number in a URL is severe. It is the kind of breach that ends up in the news precisely because it is so easy to understand and so obviously preventable.

How IDOR gets fixed

The fix is straightforward: every time your application retrieves an object based on an identifier in a request, it must verify that the requesting user has permission to access that object. This is called authorisation checking — confirming not just that the user is logged in but that they are allowed to see the specific thing they are requesting.

This check needs to be implemented consistently throughout your application, on every endpoint that retrieves user-specific data. A single missed endpoint is enough to expose your entire user base.

Yrzo AI includes IDOR scanning as one of its 44 automated security checks. The scan identifies endpoints where object references are accessible without proper authorisation checks and reports them with evidence of the vulnerability and guidance on the fix.