IDOR: the OWASP #1 vulnerability nobody takes seriously

TL;DR — IDOR is the most basic flaw in the OWASP Top 10, and also one of the most exploited. This article covers the vulnerability, recent cases in France (litige.fr, ÉduConnect), why it still persists in 2026, how to defend against it, and how a SOC actually detects it.

Introduction

In 2026, 100% of applications tested by OWASP have at least one access control flaw. Broken Access Control jumped from 5th to 1st place in the OWASP Top 10 back in 2021, and it has never left that spot since. Its simplest form? IDOR. A vulnerability so basic you learn it on day one of pentesting. And yet, in 2026, it's still leaking tens of millions of personal records in France.

What is an IDOR?

An IDOR is a vulnerability tied to access-control issues, which shows up when a direct reference to an object can be controlled by a user. This type of vulnerability allows horizontal privilege escalation (that is, accessing information belonging to other users who hold the same level of access).

Imagine a SaaS product that lets you read/write invoices based on a URL containing a specific ID for each invoice, with poorly configured access controls. That would generally allow a user to access someone else's invoices just by changing the ID in the URL.

A malicious user who sees a URL like this: https://www.saasinvoice.com/invoices/041. They'll inevitably try changing that ID to see if they can reach other invoices. If access control is misconfigured, they'll be able to access anyone's invoices.

Say they change that ID to https://www.saasinvoice.com/invoices/045. If that record exists in the database and no access check is performed, the user gets access to it without any issue — that's an IDOR. The impact of this type of vulnerability can be critical depending on the sensitivity of the data involved.

Recent real-world cases

This year France has seen a huge number of cyberattacks, and the ones involving an IDOR flaw are a minority, but they still happen. The services hit include: ÉduConnect; ANTS / France Titres; Cegedim Santé; FICOBA / DGFiP; Freemobile. These five vulnerable services cover data that matters to French citizens across the board: education (ÉduConnect), identity and official documents (ANTS / France Titres), health (Cegedim Santé), public finances (FICOBA / DGFiP), and telecoms (Freemobile). All told, that's 55.4 million exposed accounts (confirmed or claimed figures depending on the case), which shows that even after decades of having every means available to avoid these mistakes, large organizations are still letting basic flaws like this slip through.

For comparison, in 2026 France ranks among the most affected European countries, with +37% incidents in Q1 2026 alone. (Summary based on ENISA and ANSSI data, and 2025-2026 sector analyses.)

More recently, moving past Q1 2026, France went through a massive IDOR breach on litige.fr. The author claimed to have exploited a critical access-control flaw giving access to the information of more than 2 million users. According to the author's claims, the sensitive data they accessed included: first and last name; phone number; full address; internal identifier. There's no mention of passwords or documents, so the exact scope remains uncertain.

The real risks of this kind of leak are straightforward: phishing. Following a leak like this, we can all become targets of highly specific phishing emails or calls built around our own information to look authentic, in order to extract money — especially from the most vulnerable or credulous people facing this kind of scam.

My personal take on incidents like this: I think they're bound to happen, and honestly, for the greater good. What I don't appreciate is the sale of this sensitive data to malicious actors. That said, it does push cybersecurity forward and puts large organizations on notice to hire better SOC analysts or pentesters, so we're all better protected from real, malicious cyberattackers.

Why is it still so common in 2026?

The technical and structural reasons behind its persistence come down to a few pretty simple things. Let's start with the explosion of "API-first" architectures; modern applications are no longer big monoliths like before, they're thousands of interconnected APIs exchanging direct object identifiers — which is, quite literally, the definition of an IDOR. The more endpoints pile up because of APIs, the harder it becomes for developers to maintain a consistent authorization policy across every single function.

The second reason is AI-driven code generation. In 2026, using AI to generate code is nearly universal among developers. It's genuinely useful for speeding up website development or debugging, but it tends to produce functional code that pushes security to the background, simply because we don't explicitly ask for it. By leaving security out, it propagates very critical security flaws and logic flaws, which lets anyone who finds one exploit it.

The third reason is the inability of automated vulnerability scanners to detect IDOR flaws. Unlike SQLi or XSS, an IDOR isn't a code defect. The attacker's request is technically legitimate — only the authorization context is not. Classic security scanners miss it most of the time because they can't infer business logic (whether user A is allowed to access user B's invoice). Only manual penetration testing can reliably catch these.

Concrete defenses against IDOR

Defenses against IDOR are almost paradoxical: the flaw is simple, and so are the fixes. It's tempting to think that swapping sequential IDs for UUIDs solves the problem — sure, it makes the attacker's job a bit harder, but it does nothing to stop privilege escalation. Worse, with brute-force methods, anyone can still get there anyway.

To actually fix it, you need server-side authorization checks. To be clear: never trust identifiers (like a user_id) passed by the client or the URL. Always resolve the identity from the active session and verify that the requesting user actually owns the object. /me-style endpoints also eliminate IDOR risk entirely: no identifier required in the URL, the application no longer relies on variable identifiers, and the server alone determines the requester's identity via the authentication token or a secure session cookie.

As I said at the start, the best defenses are also the simplest: a proper server-side check, a shift toward /me-style endpoints, and UUIDs as a complementary layer if needed. Combine these three defenses and you eliminate the vast majority of IDOR risk on your application. To validate this in production, you can also run automated tests (CI/CD) with targeted security tests that simulate unauthorized access attempts (for example, a user trying to view another user's data) during development and continuous integration.

SOC perspective

As a SOC analyst, the priority is log analysis and behavioral indicators of compromise (IoC).

1. Since IDOR flaws don't trigger any built-in alert, the SOC has to look for behavioral anomalies in application logs:

   • Abnormal request volumes: the same user rapidly cycling through random identifiers in record time (e.g., 500 requests against different user_id values in 2 minutes).
   • Access-context shifts: a user tied to company A (or a customer role) suddenly issuing requests targeting resources belonging to company B, or to admin accounts.
   • Suspicious error rates or patterns: unusual HTTP status codes followed by a string of successes, or conversely, a high volume of requests returning similarly sized payloads.

2. For a SOC analyst to actually trace an IDOR, the SIEM needs rich application logs:

   • Don't limit yourself to network logs (source IP, destination, status code).
   • Capture the authenticated user's identifier (user_id / session_id) alongside the identifier of the resource being requested, whether in the payload or the URL.
   • Correlate this data to detect the mismatch: User.ID != Resource.Owner.ID (this SIEM correlation rule requires application logs to include both the session identifier AND the requested resource identifier. This is where things usually break down: standard application logs don't carry this information.)

3. Investigation and validation

   • The analyst pulls the source IP, the compromised account, and the scope of accessed accounts.
   • They check whether the account belongs to a tester (e.g., an internal pentester) or whether it's a genuine account compromise where the attacker is scraping the database.
   • They escalate the finding to the AppSec team to fix the underlying code.

4. Response actions (remediation / SOAR)

   • Immediate containment: if a user account is actively harvesting data through an IDOR flaw, the SOC can immediately revoke the session token or block the IP via SOAR or the WAF.
   • Continuous improvement: feed the observed attack patterns back into hardening access-validation rules across the API.

Conclusion

To wrap up, IDOR flaws are, fundamentally, childishly simple bugs — but they can turn out to be critical. It's a fairly basic flaw to defend against, and anyone running a website should check everything covered above; it's essential for protecting users and everyone's personal data. We are all targets of malicious cyberattacks, but they hit even harder when tied to large services or government platforms — our data can be leaked and used for personal gain through underhanded scams. There's no way to fully protect yourself from that. What you can do is stay alert to phishing emails: check who's sending them, how they're written, and cross-reference the information against sites like Virustotal, Phishing Initiative (a French initiative!), and Mailarnaque.fr (another French tool!).

Take care of yourself and your data.