A Teenager, an IDOR, Eleven Million French Citizens

On 15 April 2026, the Agence nationale des titres sécurisés — the French Ministry of the Interior's agency that issues national ID cards, passports, driving licences and residence permits — detected an intrusion into its portal. Five days later, the public announcement. On 25 April, French police arrested a fifteen-year-old in Paris. On 30 April he was formally charged. The agency, meanwhile, has been rebranded as France Titres.

The numbers are disputed. The official communication speaks of 11.7 million compromised accounts. The attacker, on the criminal forums where he tried to sell the dump, claimed between 12 and 18 million. The forensic investigation is still ongoing, with CNIL, ANSSI and the Paris Prosecutor's Office all involved.

The technical vector is a classic so classic it's embarrassing: an IDOR in the document management API. Multiple sources report that the attacker himself, on the forums where he listed the dump, described it as "really stupid".

What IDOR Means

IDOR stands for Insecure Direct Object Reference. In practice: an API exposes resources identified by a parameter (typically a number or a predictable identifier), and fails to verify whether the caller is actually authorised to see that specific resource.

A textbook example. An authenticated user calls the endpoint:

GET /api/citizen/12345/document

and receives their own data. If the API has an IDOR, replacing 12345 with 12346 returns another citizen's data. The system knows the caller is authenticated — the token is valid — but it never checks whether the requested resource belongs to them. Authentication is there. Object-level authorisation is missing.

In the OWASP API Security Top 10 taxonomy this is called BOLA — Broken Object Level Authorization. It has been at the top of the list since 2019, edition after edition. Not because it is exotic: because it is everywhere.

Why Such a Basic Check Keeps Failing

Three structural reasons.

First, WAFs do not catch it. An IDOR request is syntactically perfect: valid token, legitimate endpoint, parameter in the expected format. To an application firewall it is normal traffic.

Second, automated tests are bad at finding it. Vulnerability scanners know how to look for SQL injection, XSS, path traversal — known patterns. IDOR requires understanding the data model and the ownership logic of resources. It is a test that must be written case by case, for every endpoint.

Third, the code "looks fine". In code review, a function that fetches getDocument(id) from a database appears harmless. The bug is not in what it does, it is in what it doesn't do first: the check if document.owner_id != current_user.id: raise Forbidden. Its absence is invisible to the reader.

The result is that IDOR/BOLA reaches production by passing unscathed through the defensive layers the organisation believes it has.

The Operational Rule

There is one principle that closes the problem: authorisation must be per-object, not per-endpoint.

It is not enough to protect the route (/api/citizen/* requires authentication). For each individual resource returned, the backend must verify the relationship between the authenticated user and the requested resource. In concrete terms:

• At code level: middleware or decorators that apply the ownership/role check systematically, not left to the developer's discipline.
• At test level: for every endpoint that returns user data, at least one negative test that simulates user A requesting user B's resource and verifies the 403.
• At pen test level: explicitly require in scope the BOLA verification across all identity-related endpoints, not just the usual suspects.

Patterns such as opaque identifiers (UUIDs in place of sequential integers) raise the bar, but do not solve the problem. A UUID slows down brute-force enumeration, not an attacker who already knows the ID of another object.

The Lesson for Those Who Don't Manage Passports

Reading this news, there is a temptation to file it away as "a French public administration problem". That is a mistake in perspective.

The most relevant data point is not the size of the breach. It is the attacker's profile. Not a state-sponsored APT, not an organised group: a teenager with a browser and enough curiosity to alter a parameter in a URL. The technical bar required to compromise a European government agency was so low that a self-taught minor cleared it.

For those who develop or operate APIs in a small or mid-sized business, this is a very precise operational signal: the average security maturity of the ecosystem is low enough that you don't need a sophisticated adversary to become a target. You need an exposed API with BOLA and the next person who runs into it.

The perimeter is no longer the firewall. It is every single endpoint that returns an object.

Treating it with discipline is not an advanced choice. It is the baseline below which, today, no API-driven service should sit.