Une faille IDOR a exposé 19 millions de citoyens français — Voici la vulnérabilité en cause

Le 15 avril 2026, l'ANTS (Agence Nationale des Titres Sécurisés, également connue sous le nom de France Titres), l'agence française d'identité numérique, a subi une violation de données exposant les informations personnelles d'environ 19 millions de citoyens français. La cause principale était une vulnérabilité classique d'Insecure Direct Object Reference (IDOR) dans une API publique — le type de faille qui prend 20 minutes à exploiter et des années à surmonter.

Ce qui s'est réellement passé à l'ANTS

Selon les premières divulgations, les attaquants ont découvert que l'API de l'ANTS utilisait des identifiants séquentiels et prévisibles dans ses endpoints. En incrémentant ou en modifiant simplement un paramètre d'ID dans les requêtes API — par exemple /api/v1/users/1042389 modifié en /api/v1/users/1042390 — des utilisateurs non authentifiés ou disposant de faibles privilèges pouvaient récupérer les dossiers d'autres citoyens.

Les données exposées comprenaient :

• Les noms complets
• Les adresses e-mail
• Les dates de naissance
• Potentiellement des numéros de référence de documents liés aux cartes nationales d'identité et aux passeports

Avec 19 millions de dossiers concernés, cet incident figure parmi les plus importantes violations de données gouvernementales de l'histoire française. La CNIL (Commission Nationale de l'Informatique et des Libertés) a ouvert une enquête, et l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) serait impliquée dans l'analyse forensique post-incident.

Qu'est-ce qu'une vulnérabilité IDOR ?

L'IDOR (Insecure Direct Object Reference) figure au Top 10 de la sécurité des API OWASP — API1 : Broken Object Level Authorization. Son principe est trompeusement simple : une application expose un identifiant interne (ID de ligne en base de données, nom de fichier, UUID) et omet de vérifier que l'utilisateur qui effectue la requête est réellement autorisé à accéder à cet objet spécifique.

Voici un exemple minimal de code Node.js/Express vulnérable :

// VULNÉRABLE : Aucune vérification de propriété
app.get('/api/documents/:id', authenticateToken, async (req, res) => {
  const doc = await db.documents.findById(req.params.id);
  return res.json(doc); // Retourne n'importe quel document si vous connaissez l'ID
});

// SÉCURISÉ : Vérification de la propriété
app.get('/api/documents/:id', authenticateToken, async (req, res) => {
  const doc = await db.documents.findOne({
    id: req.params.id,
    ownerId: req.user.id // Doit appartenir à l'utilisateur authentifié
  });
  if (!doc) return res.status(403).json({ error: 'Interdit' });
  return res.json(doc);
});

La différence tient à une seule condition dans la requête. Les conséquences, comme l'ANTS vient de le démontrer, sont catastrophiques à grande échelle.

Pourquoi l'IDOR est si dangereuse dans les API — et si répandue

L'IDOR était également le vecteur d'attaque à l'origine de la violation ÉduConnect divulguée à peu près à la même période, où 7,2 millions de bulletins scolaires d'élèves français ont été consultés en modifiant un seul chiffre dans une URL. Deux systèmes gouvernementaux massifs, la même erreur fondamentale.

Ce schéma n'est pas une coïncidence. L'IDOR est omniprésente dans les architectures API-first pour plusieurs raisons :

1. Les développeurs font trop confiance à l'authentification. Une fois qu'un utilisateur est authentifié, les vérifications d'autorisation sur les objets individuels sont souvent omises ou appliquées de manière inconsistante. L'authentification confirme qui vous êtes, pas ce à quoi vous pouvez accéder.

2. Les IDs entiers séquentiels sont énumérables par conception. Si vos IDs utilisateur sont 10001, 10002, 10003..., un attaquant n'a pas besoin de recourir à la force brute. Il lui suffit d'itérer.

3. Les réponses d'API sont lisibles par machine et peuvent être récupérées en masse. Contrairement à une interface web qui ralentit un humain, une API vulnérable peut être scrapée de manière programmatique. Un simple script Python avec requests peut exfiltrer des milliers de dossiers par minute.

4. L'IDOR ne déclenche pas les outils de sécurité traditionnels. Les pare-feu et les WAF ne peuvent généralement pas distinguer une requête légitime d'une attaque IDOR — les deux ressemblent à des appels API authentifiés normaux.

L'impact commercial et juridique

Pour les agences gouvernementales comme pour les entreprises privées, les violations par IDOR entraînent de graves conséquences en 2026 :

• Amendes RGPD : En vertu de l'article 83(4), les organisations peuvent être sanctionnées jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial pour des mesures techniques inadéquates. Pour une violation portant sur 19 millions de dossiers, l'exposition maximale est considérable.
• Notification obligatoire de violation : Le RGPD impose la notification aux autorités de contrôle (la CNIL en France) dans les 72 heures suivant la prise de connaissance d'une violation.
• Atteinte à la réputation : Les citoyens dont les données d'identité nationale ont été exposées font face à un risque accru de phishing et de fraude à l'identité pendant des années.
• Risque d'action collective : Des associations françaises de défense des consommateurs ont déjà signalé leur intention d'engager des actions en justice collectives.

Pour les entreprises privées — plateformes SaaS, sites e-commerce, applications fintech — une violation similaire sans les ressources d'une agence nationale serait probablement fatale.

Comment détecter les vulnérabilités IDOR avant les attaquants

La réalité frustrante est que l'IDOR est très détectable avec les bons outils. Voici ce qu'un audit de sécurité rigoureux recherche :

Analyse automatisée

Les scanners de sécurité peuvent identifier de manière systématique les endpoints d'API qui acceptent des identifiants d'objets et tester si l'autorisation est correctement appliquée. Cela comprend :

• La détection des endpoints avec des IDs numériques, des UUIDs ou des slugs dans les chemins et les paramètres de requête
• La tentative d'accès aux ressources dans différents contextes d'utilisateurs authentifiés
• Le signalement des endpoints qui retournent 200 OK pour un accès à des objets appartenant à d'autres utilisateurs

Des outils comme Scorra effectuent une détection automatisée des IDOR dans le cadre d'analyses de sécurité API plus larges — en explorant les endpoints de votre application, en identifiant les schémas de référence d'objets et en testant les limites d'autorisation sans nécessiter de configuration manuelle de test de pénétration.

Liste de contrôle pour la revue de code manuelle

Si vous auditez votre propre code, vérifiez chaque endpoint de récupération de données :

☐ Chaque requête en base de données inclut-elle l'ID de l'utilisateur authentifié comme condition de filtre ?
☐ Des UUIDs sont-ils utilisés à la place des entiers séquentiels ? (Plus difficiles à énumérer, mais PAS une solution de sécurité à eux seuls)
☐ Les vérifications d'autorisation sont-elles appliquées au niveau du service/des données, et pas uniquement au niveau de la route ?
☐ Vos tests d'API incluent-ils des scénarios d'accès inter-utilisateurs ?
☐ Les endpoints d'administration/internes sont-ils séparés des routes publiques ?

Tests avec OWASP ZAP ou Burp Suite

Pour les développeurs effectuant des tests manuels : capturez une requête API légitime qui retourne vos propres données, remplacez votre ID d'objet par celui d'un autre utilisateur (obtenu via un autre compte) et observez la réponse. Si vous obtenez un 200 au lieu d'un 403, vous avez un IDOR.

Correctifs pratiques que les développeurs devraient mettre en œuvre dès aujourd'hui

1. Limitez toujours les requêtes à l'utilisateur authentifié. C'est non négociable. Chaque findById() devrait devenir findByIdAndUser(id, userId).

2. Utilisez des UUIDs (v4) pour les IDs publics. Les entiers séquentiels sont un cadeau pour les attaquants souhaitant énumérer vos données. Les UUIDs ne sont pas un contrôle de sécurité en soi, mais ils élèvent significativement le niveau de difficulté.

3. Implémentez un middleware d'autorisation au niveau des objets. Ne répétez pas la vérification de propriété dans chaque contrôleur — abstractions via un middleware réutilisable ou une couche de politique.

4. Ajoutez des tests d'accès inter-utilisateurs à votre pipeline CI/CD. Les tests automatisés devraient créer deux comptes utilisateur et vérifier que l'utilisateur A ne peut pas accéder aux ressources de l'utilisateur B.

5. Limitez le débit et surveillez les schémas d'énumération API. Des requêtes séquentielles rapides vers le même schéma d'endpoint devraient déclencher des alertes.

Ce qu'il faut retenir

La violation de l'ANTS est un cas d'école illustrant ce qui arrive lorsque l'authentification est traitée comme un substitut à l'autorisation. Dix-neuf millions de personnes ont vu leurs données d'identité gouvernementale exposées à cause d'une clause WHERE user_id = ? manquante. La violation d'ÉduConnect a touché 7,2 millions d'élèves pour la même raison, à peu près au même moment.

L'IDOR n'est pas un vecteur d'attaque nouveau. Il figure dans le Top 10 de l'OWASP depuis des années. C'est le premier élément du Top 10 de la sécurité des API. Et cela continue de se produire parce que les développeurs, naturellement concentrés sur la livraison de fonctionnalités, sautent souvent le travail peu glamour de vérification de la propriété des objets à chaque requête.

Si vous construisez une API — qu'il s'agisse d'une plateforme SaaS, d'une application Shopify personnalisée ou d'un endpoint REST WordPress — effectuez un scan de sécurité avant qu'un titre mentionnant 19 millions de dossiers ne soit écrit sur votre plateforme.

Analysez votre application pour détecter les IDOR et autres vulnérabilités API avec Scorra →

---

Connexes : Top 10 de la sécurité des API OWASP — API1:2023 Broken Object Level Authorization | Entrées de la base de données CVE pour les vulnérabilités de type IDOR | Recommandations de la CNIL sur la notification des violations