IDOR Flaw Exposed 19 Million French Citizens — Here's the Vulnerability Behind It

On April 15, 2026, France's national digital identity agency ANTS (Agence Nationale des Titres Sécurisés, also known as France Titres) suffered a data breach exposing the personal records of approximately 19 million French citizens. The root cause was a classic Insecure Direct Object Reference (IDOR) vulnerability in a public-facing API — the kind of bug that takes 20 minutes to exploit and years to recover from.

What Actually Happened at ANTS

According to early disclosures, attackers discovered that the ANTS API used predictable, sequential identifiers in its endpoints. By simply incrementing or modifying an ID parameter in API requests — think /api/v1/users/1042389 changed to /api/v1/users/1042390 — unauthenticated or low-privileged users could retrieve records belonging to other citizens.

The exposed data included:

• Full names
• Email addresses
• Dates of birth
• Potentially document reference numbers tied to national ID cards and passports

With 19 million records in scope, this ranks among the largest government data breaches in French history. The CNIL (Commission Nationale de l'Informatique et des Libertés) has opened an investigation, and ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) is reportedly involved in the post-incident forensic analysis.

What Is an IDOR Vulnerability?

IDOR (Insecure Direct Object Reference) sits at OWASP API Security Top 10 — API1: Broken Object Level Authorization. It's deceptively simple: an application exposes an internal identifier (database row ID, filename, UUID) and fails to verify that the requesting user is actually authorized to access that specific object.

Here's a minimal example of vulnerable Node.js/Express code:

// VULNERABLE: No ownership check
app.get('/api/documents/:id', authenticateToken, async (req, res) => {
  const doc = await db.documents.findById(req.params.id);
  return res.json(doc); // Returns any document if you know the ID
});

// SECURE: Enforce ownership
app.get('/api/documents/:id', authenticateToken, async (req, res) => {
  const doc = await db.documents.findOne({
    id: req.params.id,
    ownerId: req.user.id // Must belong to the authenticated user
  });
  if (!doc) return res.status(403).json({ error: 'Forbidden' });
  return res.json(doc);
});

The difference is a single query condition. The consequences, as ANTS just demonstrated, are catastrophic at scale.

Why IDOR Is So Dangerous in APIs — And So Common

IDOR was also the attack vector behind the ÉduConnect breach disclosed around the same period, where 7.2 million French student school reports were accessed by modifying a single digit in a URL. Two massive government systems, same fundamental mistake.

This pattern is not coincidental. IDOR is rampant in API-first architectures for several reasons:

1. Developers trust authentication too heavily. Once a user is authenticated, authorization checks on individual objects are often skipped or inconsistently applied. Auth confirms who you are, not what you can access.

2. Sequential integer IDs are enumerable by design. If your user IDs are 10001, 10002, 10003..., an attacker doesn't need to brute-force anything. They just iterate.

3. API responses are machine-readable and bulk-scrapeable. Unlike a web UI that slows a human down, a vulnerable API can be scraped programmatically. A simple Python script with requests can exfiltrate thousands of records per minute.

4. IDOR doesn't trigger traditional security tools. Firewalls and WAFs generally can't distinguish a legitimate request from an IDOR attack — both look like normal authenticated API calls.

The Business and Legal Impact

For government agencies and private companies alike, IDOR breaches carry severe consequences in 2026:

• GDPR fines: Under Article 83(4), organizations can face up to €10 million or 2% of global annual turnover for inadequate technical measures. For a breach of 19 million records, maximum exposure is significant.
• Mandatory breach notification: GDPR requires notification to supervisory authorities (CNIL in France) within 72 hours of becoming aware of a breach.
• Reputational damage: Citizens whose national ID data was exposed face elevated phishing and identity fraud risk for years.
• Class action exposure: French consumer advocacy groups have already signaled intent to pursue collective legal action.

For private businesses — SaaS platforms, e-commerce sites, fintech apps — a similar breach without the resources of a national agency would likely be existential.

How to Detect IDOR Vulnerabilities Before Attackers Do

The frustrating reality is that IDOR is highly detectable with the right tooling. Here's what a proper security audit looks for:

Automated Scanning

Security scanners can systematically identify API endpoints that accept object identifiers and test whether authorization is properly enforced. This includes:

• Detecting endpoints with numeric IDs, UUIDs, or slugs in paths and query parameters
• Attempting to access resources across different authenticated user contexts
• Flagging endpoints that return 200 OK for cross-user object access

Tools like Scorra perform automated IDOR detection as part of broader API security scans — crawling your application's endpoints, identifying object reference patterns, and testing authorization boundaries without requiring manual pen-test setup.

Manual Code Review Checklist

If you're auditing your own code, check every data retrieval endpoint:

☐ Does every database query include the authenticated user's ID as a filter condition?
☐ Are UUIDs used instead of sequential integers? (Harder to enumerate, but NOT a security fix alone)
☐ Are authorization checks applied at the service/data layer, not just the route layer?
☐ Do your API tests include cross-user access scenarios?
☐ Are admin/internal endpoints separated from public-facing routes?

Testing with OWASP ZAP or Burp Suite

For developers doing manual testing: capture a legitimate API request that returns your own data, swap your object ID for another user's ID (obtained via another account), and observe the response. If you get a 200 instead of a 403, you have an IDOR.

Practical Fixes Developers Should Implement Today

1. Always scope queries to the authenticated user. This is non-negotiable. Every findById() should become findByIdAndUser(id, userId).

2. Use UUIDs (v4) for public-facing IDs. Sequential integers are an enumeration gift to attackers. UUIDs are not a security control, but they raise the bar significantly.

3. Implement object-level authorization middleware. Don't repeat the ownership check in every controller — abstract it into reusable middleware or a policy layer.

4. Add cross-user access tests to your CI/CD pipeline. Automated tests should create two user accounts and verify that User A cannot access User B's resources.

5. Rate-limit and monitor API enumeration patterns. Rapid sequential requests to the same endpoint pattern should trigger alerts.

The Takeaway

The ANTS breach is a textbook case of what happens when authentication is treated as a substitute for authorization. Nineteen million people had their government identity data exposed because of a missing WHERE user_id = ? clause. The ÉduConnect breach hit 7.2 million students for the same reason, around the same time.

IDOR isn't a novel attack vector. It's been in the OWASP Top 10 for years. It's the first item in the API Security Top 10. And it keeps happening because developers, understandably focused on shipping features, often skip the unglamorous work of verifying object ownership on every single request.

If you're building an API — whether it's a SaaS platform, a Shopify custom app, or a WordPress REST endpoint — run a security scan before a 19-million-record headline is written about your platform.

Scan your application for IDOR and other API vulnerabilities with Scorra →

---

Related: OWASP API Security Top 10 — API1:2023 Broken Object Level Authorization | CVE database entries for IDOR-class vulnerabilities | CNIL breach notification guidance