Fuite ANTS 2026 : 11,7 millions de comptes, l'hypothèse IDOR

Que sait-on vraiment de l'incident ANTS ?

L'ANTS indique avoir détecté un incident le 15 avril 2026 et l'a rendu public le 20 avril. Le ministère de l'Intérieur a signalé les faits au parquet de Paris, et l'Office anti-cybercriminalité (OFAC) mène l'enquête. Le 21 avril, le ministère a annoncé 11,7 millions de comptes concernés. Un vendeur sur un forum clandestin revendiquerait jusqu'à 19 millions d'enregistrements : ce chiffre n'est pas confirmé.

Les données citées pour les comptes de particuliers sont l'identifiant de connexion, la civilité, le nom, les prénoms, l'adresse e-mail, la date de naissance et l'identifiant unique du compte. Selon les cas, l'adresse postale, le lieu de naissance et le numéro de téléphone peuvent s'y ajouter. Les pièces jointes aux dossiers ne seraient pas concernées. Aucun communiqué officiel ne décrit la cause : le qualificatif IDOR vient de sources secondaires et reste à prendre comme une hypothèse.

Qu'est-ce qu'une IDOR et pourquoi est-elle si répandue ?

Une IDOR survient quand une application désigne une ressource (compte, dossier, document) par un identifiant et ne vérifie pas que l'utilisateur connecté a le droit d'y accéder. Si l'API répond aussi bien à /api/comptes/4512889 qu'à /api/comptes/4512890, n'importe quel utilisateur peut parcourir la base en incrémentant le numéro.

L'OWASP classe cette famille en tête de son Top 10 des API sous le nom BOLA (Broken Object Level Authorization, API1:2023). Elle est fréquente parce que l'authentification fonctionne : l'utilisateur est bien connecté. Il manque seulement la deuxième question, celle de l'autorisation sur cet objet précis. Nous détaillons ce schéma dans notre article sur BOLA et IDOR dans les API et dans le guide OWASP API Top 10.

Qui est concerné par ce type de faille ?

Toute application dont l'API accepte un identifiant venant du client : portails citoyens, espaces clients, SIRH, plateformes de santé, marketplaces. L'exposition augmente avec le volume de comptes et avec la prévisibilité des identifiants (numéros séquentiels, e-mails, immatriculations). Pour l'incident ANTS, les chiffres officiels en font l'une des plus grosses fuites de l'année en France, à comparer à celle de France Travail en 2024.

Le risque principal pour les usagers est l'hameçonnage ciblé : un e-mail qui cite votre nom, votre date de naissance et une démarche réelle est difficile à distinguer d'un message légitime.

Comment tester une IDOR en pratique ?

La réponse courte : avec deux comptes de test et un proxy d'interception. Le protocole que nous appliquons :

1. Lister chaque endpoint qui contient un identifiant (chemin, query string, corps JSON, en-tête) et noter l'objet visé.
2. Créer deux comptes de même niveau (A et B), puis rejouer avec la session de A les requêtes portant les identifiants de B. Une réponse 200 avec les données de B est une IDOR.
3. Rejouer avec un compte de niveau inférieur sur les ressources d'un compte plus privilégié, pour détecter l'élévation verticale.
4. Tester toutes les méthodes : un GET peut être protégé alors que PUT ou DELETE ne le sont pas.
5. Tester les identifiants indirects : numéros de dossier, références de document, noms de fichiers dans un stockage d'objets.

Règle de sécurité : on compte les enregistrements lisibles, on ne télécharge pas les données personnelles réelles, et on s'arrête dès la preuve établie.

Comment corriger et empêcher le retour d'une IDOR ?

Le correctif est une vérification côté serveur à chaque accès : l'objet demandé appartient-il à l'utilisateur de la session, ou celui-ci a-t-il un droit explicite dessus ? Il vaut mieux centraliser ce contrôle (middleware, politique par ressource, règles de sécurité au niveau des lignes en base) que le répéter dans chaque route.

Des identifiants non prévisibles (UUID) compliquent l'énumération, mais ils complètent le contrôle d'autorisation sans le remplacer. Ajoutez des tests automatisés à deux comptes dans votre intégration continue, une limitation de débit sur les endpoints de lecture et une alerte sur les parcours d'identifiants séquentiels. La fiche OWASP sur la prévention des IDOR décrit ces mesures.

Qu'est-ce qui change quand un agent IA a accès à cette API ?

Un agent IA qui appelle l'API au nom de l'utilisateur transforme une IDOR de curiosité en moyen d'extraction automatisé. Trois différences pèsent dans l'analyse.

L'identité de l'agent n'est pas celle de l'utilisateur. Beaucoup d'agents utilisent un jeton de service puissant, parfois sans restriction par utilisateur. Si l'API ne contrôle l'autorisation qu'à partir du jeton de service, l'agent peut lire n'importe quel compte, et l'utilisateur peut lui demander de le faire. C'est l'analogue d'un confused deputy : l'agent a des droits que l'utilisateur n'a pas.

Les identifiants circulent dans le contexte du modèle. Le modèle voit les identifiants renvoyés par les outils et peut les réutiliser. Une injection de prompt indirecte, glissée dans un e-mail ou un document que l'agent lit, peut lui demander de rappeler l'API avec d'autres identifiants et de renvoyer le résultat vers l'extérieur. Voir notre page sur l'injection de prompt.

La vitesse change l'échelle. Un agent boucle sur des milliers d'identifiants sans fatigue. Un contrôle absent côté serveur devient exploitable en masse, avec une trace qui ressemble à un usage légitime du compte de service.

Les défenses sont de transmettre l'identité de l'utilisateur final jusqu'à l'API (jeton délégué à portée limitée, pas de jeton de service général), de contrôler l'autorisation objet par objet côté serveur, de limiter les appels par session d'agent et de journaliser chaque appel d'outil avec l'identité demandeuse. Cela correspond au risque LLM06 (Excessive Agency) du Top 10 OWASP pour les applications LLM. Pour aller plus loin, consultez notre page sur la sécurité des agents IA.

Comment vérifier votre exposition ?

Commencez par un inventaire : quelles API acceptent des identifiants, lesquelles sont appelées par un agent, avec quel jeton ? Ensuite, jouez le test à deux comptes sur ces endpoints, avec le jeton de l'agent et avec celui de l'utilisateur. Notre offre Red Team Agent Express (1 900 €, 5 jours) teste précisément ce cas : un agent réel, ses outils, ses identifiants et les contrôles d'autorisation derrière, avec des preuves reproductibles à la fin.