Il suffisait de changer un chiffre dans une adresse pour consulter le dossier d'un autre citoyen. Ce type de faille, appelé IDOR, est à la fois l'un des plus simples à exploiter et l'un des plus dévastateurs. En 2026, il reste la première cause de fuites de données massives, comme l'a rappelé la compromission de 11,7 millions de comptes du portail France Titres (ex-ANTS).
Qu'est-ce qu'une IDOR ?
Une IDOR (Insecure Direct Object Reference, référence directe à un objet non sécurisée) survient lorsqu'une application expose un identifiant interne - un numéro de dossier, un identifiant utilisateur - sans vérifier que la personne qui le demande a le droit d'y accéder. L'application authentifie bien l'utilisateur (elle sait qui il est), mais oublie de contrôler l'autorisation (a-t-il le droit d'accéder à cet objet précis ?). L'IDOR relève de la catégorie Broken Access Control, en tête du top 10 de l'OWASP.
Le cas France Titres (ANTS)
Le ministère de l'Intérieur a confirmé, en avril 2026, la compromission d'environ 11,7 millions de comptes du portail France Titres. Le mécanisme : un attaquant pouvait modifier un identifiant numérique dans une requête envoyée à l'API du portail pour accéder aux données d'un autre usager, sans aucun contrôle d'autorisation côté serveur. Aucun exploit sophistiqué : juste un identifiant prévisible et une vérification manquante.
Sources : OWASP et couverture presse de la fuite ANTS - voir les liens en bas d'article.
Pourquoi cette faille est si répandue
Les équipes concentrent souvent leurs efforts sur l'authentification (prouver qui l'on est) et négligent l'autorisation fine (vérifier le droit d'accès objet par objet). Le phénomène s'aggrave avec les API : chaque nouvel endpoint multiplie les points où un contrôle peut manquer, et les API sont souvent moins surveillées que les interfaces web. Résultat : une faille invisible à l'œil nu, mais triviale à exploiter en masse par un script.
Connectez-vous avec deux comptes distincts. Depuis le compte A, tentez d'accéder à une ressource du compte B en modifiant simplement l'identifiant dans l'URL ou la requête API. Si vous voyez les données de B, vous avez une IDOR. C'est l'un des premiers tests menés lors d'un test d'intrusion applicatif.
Comment s'en prémunir
- Contrôler l'autorisation côté serveur, systématiquement, à chaque accès à un objet - jamais côté client, jamais « par confiance ».
- Refuser par défaut : un accès n'est autorisé que s'il est explicitement permis.
- Utiliser des identifiants non devinables (UUID) pour compliquer l'énumération - utile, mais jamais suffisant seul : le contrôle d'autorisation reste indispensable.
- Tester par des pentests applicatifs et des tests d'API réguliers, avant et après mise en production.
- Journaliser et surveiller les accès anormaux (un compte qui parcourt des milliers d'identifiants).
Ces réflexes s'inscrivent dans une démarche plus large de maîtrise de la surface d'attaque et de sécurité des API.
En résumé
L'IDOR n'est pas une faille exotique : c'est un contrôle d'autorisation oublié, aux conséquences potentiellement massives. La parade est connue - vérifier le droit d'accès, côté serveur, à chaque objet - mais elle exige rigueur et tests. Dans un monde d'API, c'est l'un des points où l'écart entre « ça marche » et « c'est sûr » coûte le plus cher.
Kenawek recherche les IDOR et les défauts de contrôle d'accès dans vos applications et API, et vous aide à les corriger durablement. Parlons-en.