Retour au blog
Fuite de donnéesIDORSecteur public

ANTS / France Titres 2026 : une simple faille IDOR expose 11,7 millions de comptes

Publié le 2026-09-036 min de lectureCleanIssue

> En bref : Le 15 avril 2026, l'Agence nationale des titres sécurisés (ANTS) détecte un accès illégitime sur son portail ants.gouv.fr, qui gère les démarches de carte grise, permis de conduire et cartes d'identité. La cause : une vulnérabilité IDOR (Insecure Direct Object Reference) triviale, exploitable en modifiant simplement un identifiant dans une URL ou une requête API, sans authentification renforcée ni technique d'intrusion avancée. Bilan officiel : 11,7 millions de comptes exposés ; l'attaquant en revendique jusqu'à 19 millions. Le ministère de l'Intérieur, la CNIL, l'ANSSI et l'OFAC (Office anti-cybercriminalité) ont été saisis.

Une IDOR, la vulnérabilité la plus simple à comprendre — et pourtant

Une IDOR consiste à référencer une ressource (un compte, un dossier, un document) par un identifiant direct et prévisible dans une URL ou un appel API, sans vérifier que l'utilisateur authentifié a réellement le droit d'accéder à *cette* ressource précise. Concrètement : si votre compte est le numéro 4 512 890 et que l'API répond aussi bien à /api/comptes/4512889 qu'à /api/comptes/4512890, n'importe quel utilisateur connecté peut parcourir tous les comptes de la base en incrémentant l'identifiant.

C'est exactement ce qui s'est produit sur ants.gouv.fr : en changeant un identifiant dans une requête, un attaquant a pu consulter les données d'autres comptes sans aucun contrôle d'autorisation côté serveur. Aucune faille zero-day, aucun exploit sophistiqué — une vérification manquante, du type if (compte.id !== session.user.id) return 403, qui n'a jamais été écrite ou qui a été contournée sur un endpoint spécifique.

Ce qui a été exposé (et ce qui ne l'a pas été)

Pour les particuliers : identifiants de connexion, civilité, nom, prénoms, adresse email, date de naissance et identifiant unique de compte, avec selon les cas adresse postale, lieu de naissance et numéro de téléphone. Pour les professionnels : raison sociale, numéro SIREN, numéros d'habilitation et de licence.

Les pièces jointes (photos, justificatifs) et les données biométriques n'auraient pas été compromises — un point important qui limite (sans l'annuler) le risque d'usurpation d'identité complète. Le risque principal reste le phishing ciblé et hautement crédible : un email prétendant venir de l'ANTS, personnalisé avec le nom, la date de naissance et l'historique de démarches réelles d'un usager, est presque impossible à distinguer d'une communication légitime.

Le chiffre qui interroge : 11,7 millions vs 19 millions

L'écart entre le chiffre officiel (11,7 millions de comptes) et la revendication de l'attaquant (18 à 19 millions d'enregistrements) illustre une réalité fréquente après ce type d'incident : l'organisation victime communique sur ce qu'elle peut confirmer techniquement (logs d'accès identifiés), tandis que l'attaquant peut inclure des doublons, des tentatives échouées ou des extrapolations dans son propre décompte. Dans les deux cas, l'ordre de grandeur — plusieurs dizaines de millions de Français potentiellement concernés sur un service quasi obligatoire pour immatriculer un véhicule ou renouveler une pièce d'identité — en fait l'une des fuites les plus larges de l'année en France.

Comment un audit détecte une IDOR avant qu'elle ne soit exploitée

Les IDOR sont l'une des catégories les plus fréquemment trouvées lors de nos audits, et l'une des plus simples à corriger une fois identifiées — ce qui rend leur présence en production d'autant plus évitable :

  • Cartographier chaque endpoint qui accepte un identifiant en paramètre (URL, body, query string) et vérifier systématiquement le contrôle d'autorisation associé, pas seulement l'authentification.
  • Tester avec deux comptes de niveaux différents : un compte standard peut-il accéder, en modifiant un ID, aux données d'un autre compte standard ou d'un compte plus privilégié ?
  • Ne jamais faire confiance aux identifiants séquentiels côté client : privilégier des UUID non prévisibles côté API, en complément — pas en remplacement — du contrôle d'autorisation serveur.
  • Auditer aussi les endpoints internes ou d'administration, souvent moins testés que les parcours utilisateurs principaux mais tout aussi exposés via l'API publique.
  • Ce que doivent faire les organisations exposées à ce schéma

    Si votre service expose une API consommée par une application web ou mobile — ce qui concerne la quasi-totalité des SaaS RH, paie et recrutement — la question à se poser n'est pas « avons-nous une authentification forte » mais « chaque appel API vérifie-t-il, pour *cette* ressource précise, que l'utilisateur courant y a droit ». Ce sont deux contrôles différents, et seul le second empêche une IDOR. Un audit en conditions réelles avec plusieurs comptes de test à des niveaux de privilège différents reste la méthode la plus fiable pour détecter ce type de vulnérabilité avant qu'un attaquant externe ne le fasse à votre place.

    Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.

    Besoin d'une revue externe de votre SaaS RH ?

    Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

    Parler de votre audit