Why multi-factor authentication did not contain a wave of French data leaks

A string of data leaks that hit French organizations from the summer of 2025 onward shared an uncomfortable pattern: no technical vulnerability was identified, a valid account simply logged in and then read tens or even hundreds of thousands of records. That observation comes from Jules Robineau, writing on dev.to, who uses the incidents to argue that multi-factor authentication answers the wrong question for this class of breach. It confirms who is at the door, but says nothing about how much data they carry out.

The incidents cited

According to the post, the motivating cases include France Travail, which after July 2025 committed to accelerating two-factor authentication on the affected tool, SFR, and a leak at the French tax administration, which responded by planning stronger authentication for all staff by the end of 2026. Robineau frames his snapshot as of October 31, 2026, separating statements made by the organizations from third-party accounts, and he cautions that the cases do not all establish the same attack path.

One December 2025 case stands out: an attacker reportedly created two new accounts carrying the rights of a real one. As the post puts it, MFA checks the person logging in, not whether an account should exist in the first place.

Why MFA does not stop the exfiltration

Robineau identifies three situations where an account clears, or sidesteps, authentication and permissions yet still extracts abnormal volumes:

• Credential-stealing malware can lift browser session cookies that have already passed MFA, handing the attacker a fully authenticated session.
• An account with permission to create other accounts can mint additional privileged access, as in the December 2025 case.
• A perfectly legitimate account, running a badly tuned script or a mistaken export, can read far more than its normal activity requires.

In all three scenarios, each individual request looks unremarkable: the account is logged in, it holds the required permission, and the application answers. The question nobody asks is how many records have left.

Per-request authorization has no memory

The two dominant authorization models, role-based access control and attribute-based access control, judge one request at a time. Robineau, who says he has built both kinds of systems, notes that a classic permission rule keeps no tally of previous answers. If an account is allowed to read an entire directory, the rule will reply yes 62,848 times in the post's illustration, and every single reply is technically correct.

The proposed fix: smaller scope, then a read budget

The post recommends shrinking what an account can see before trying to count anything. An account that can read everything turns every credential theft into a full leak. Concretely:

• Restrict each account to its own slice of data, so a salesperson sees their customers rather than the whole company's.
• Treat the right to create accounts as its own separately monitored permission.
• Cap API page size, because an endpoint accepting a limit of 100,000 records is effectively an export facility.
• Make bulk export a distinct permission from ordinary on-screen reads.
• Give internal tools read-only database accounts limited to a few views.

On top of that, Robineau proposes a read budget: a ceiling on the number of records an account can read per hour, after which the application refuses further reads and warns someone. He stresses that the budget must count records, not requests, since a conventional rate limiter counting calls per minute will happily allow a single call that returns 10,000 records. He also notes that after the tax leak, the French government floated the same idea of access quotas applied everywhere.

A short Go middleware example in the post sketches the mechanics: the account identity comes from the authentication layer and never from a request parameter, each request reserves at most 100 records against the budget, and an over-budget request receives an HTTP 429 response plus a logged warning. The validated limit is then passed into the SQL query itself rather than being re-read from the raw query string.

Why it matters

Most security spending goes to the front door, yet these leaks happened after the front door opened correctly. MFA remains the best defense against stolen passwords, and the affected organizations were right to deploy it, but it caps the blast radius only when paired with scope limits and volume controls. For any web service, back office, or API holding customer records, the practical lesson is to assume a session will eventually be stolen and to design so the damage is bounded. Rate limiting per request is common engineering practice; counting the records actually returned is rare, and records are precisely what leak.