Sécurité des API : la fuite de l'ANTS n'est pas un problème de référentiel

Ce qui s'est passé

Le 15 avril 2026, le portail de l'Agence nationale des titres sécurisés — devenue France Titres — a subi une intrusion. Le ministère de l'Intérieur retient 11,7 millions de comptes concernés ; l'attaquant en revendique 18 à 19 millions, mis en vente sur un forum. Les données exposées comprennent identifiant de connexion, état civil, date de naissance et adresse électronique.

Le vecteur : une IDOR. Une référence directe à un objet, exposée côté client, sans vérification d'autorisation côté serveur. Modifier un identifiant dans une requête suffisait à consulter le dossier d'un autre usager.

La personne mise en cause a 15 ans.

Rien de neuf, et c'est bien le problème

IDOR relève de Broken Access Control, première entrée du Top 10 de l'OWASP. Côté API, la même classe apparaît sous l'intitulé BOLA — Broken Object Level Authorization — en tête de l'OWASP API Security Top 10.

Autrement dit : la faille la plus documentée du métier, en première position de deux classements de référence, exploitée sur une plateforme régalienne par un adolescent.

L'écart entre l'effort d'attaque et l'ampleur du dommage est ici vertigineux. Ce n'est pas le signe d'un adversaire sophistiqué. C'est le signe d'un contrôle absent.

Ce n'est pas un déficit de référentiel

La tentation, après ce genre d'incident, consiste à réclamer un nouveau cadre, une nouvelle norme, un nouveau plan. C'est un contresens.

Le corpus existe, il est public, gratuit, mature et largement traduit :

• l'OWASP publie le Top 10, l'API Security Top 10, l'ASVS — un référentiel de vérification par niveaux directement utilisable comme grille de recette — et les Cheat Sheets, qui traitent explicitement l'autorisation ;
• l'ANSSI documente les bonnes pratiques de développement et de sécurisation applicative depuis des années ;
• la CNIL met à disposition un guide RGPD du développeur qui couvre précisément la question des accès aux données personnelles.

Rien à inventer. Rien à financer. Rien à attendre.

Le problème n'est donc pas normatif. Il est disciplinaire : ces règles élémentaires ne sont pas appliquées de façon systématique dans les chaînes de production logicielle. Et un référentiel supplémentaire ne changera rien à cela, pas plus qu'une énième obligation déclarative.

La sanction n'est pas du côté où on l'attend

On attend la sanction du côté de l'attaquant. Elle tombe ailleurs.

Le 22 janvier 2026, la CNIL a sanctionné France Travail de 5 millions d'euros à la suite d'une fuite, en retenant un manquement à l'obligation de sécurité. Le principe posé est difficile à ignorer : le statut de victime ne suffit plus. L'insuffisance des mesures s'apprécie indépendamment de l'attaque, et cela vaut pour un organisme public.

Le coût d'un contrôle absent ne se mesure donc plus seulement en incident, mais en sanction — et en confiance perdue auprès des usagers.

Ce qui sépare connaître et appliquer

Si votre organisation expose des données personnelles via des API, l'enjeu n'est pas de savoir si vos équipes connaissent l'OWASP. C'est de savoir ce que votre chaîne de livraison empêche effectivement de partir en production.

Entre les deux, il y a une méthode — celle qui sort le contrôle d'accès du champ de l'arbitrage et l'inscrit dans ce qui définit une fonctionnalité terminée. Il y a une expertise, qui sait où le risque se loge réellement dans une application donnée, plutôt que de dérouler une grille générique. Et il y a une expérience, celle des systèmes qu'on a vus vieillir, se complexifier et laisser passer, au fil des années, ce que personne n'avait décidé de laisser passer.

Un contrôle qu'on ne peut pas prouver est un contrôle qu'on ne peut pas garantir. Cette différence ne se joue presque jamais dans le code. Elle se joue dans la méthode qui décide de ce qui est terminé.