Pentest, audit, red team : quelles différences et quand les utiliser.
Trois approches complémentaires pour évaluer sa sécurité : ce qui les distingue vraiment et quand y recourir.
Imaginez un vestiaire de théâtre. Vous tendez votre ticket numéro 42, l'employé va chercher le manteau accroché au 42, vous le rend. Système parfait, tant que chacun présente son propre ticket. Maintenant imaginez un employé si pressé qu'il ne regarde même plus le ticket que vous avez en main : il vous demande juste « quel numéro ? », vous répondez « 43 », et il vous tend le manteau du voisin sans sourciller. Vous repartez avec un bien qui n'est pas le vôtre, sans effraction, sans violence, simplement parce que personne n'a vérifié que le 43 vous appartenait. Cette scène, transposée à un site web, porte un nom : l'IDOR.
Il suffisait, dans le cas qui nous occupe, de changer un chiffre dans une adresse pour consulter le dossier d'un autre citoyen. Cette faille est à la fois l'une des plus simples à exploiter et l'une des plus dévastatrices. En 2026, elle 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).
En résumé
- Une IDOR, c'est le vestiaire où l'employé ne regarde plus votre ticket : vous annoncez « 43 » et il vous tend le manteau du voisin. Sans effraction, parce que personne n'a vérifié que le 43 vous appartenait.
- Toute la faille tient dans une distinction que l'on confond dans l'urgence : authentifier n'est pas autoriser. L'application sait qui vous êtes, mais oublie de vérifier votre droit sur cet objet précis.
- Elle relève du Broken Access Control, en tête du top 10 de l'OWASP, et reste la première cause de fuites de données massives.
- Le portail France Titres (ex-ANTS) : 11,7 millions de comptes compromis en avril 2026 en modifiant un identifiant numérique dans une requête d'API. Aucun exploit sophistiqué - un identifiant prévisible et un contrôle manquant.
- Le test qui la révèle tient en deux comptes : depuis le compte A, tenter d'atteindre une ressource de B en changeant l'identifiant. Si les données de B s'affichent, c'est une IDOR.
- La parade est connue : contrôle d'autorisation côté serveur à chaque accès, refus par défaut, identifiants non devinables (utiles mais jamais suffisants seuls), tests d'API, journalisation des parcours anormaux.
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. Toute la faille tient dans une distinction que les développeurs pressés confondent : authentifier n'est pas autoriser. L'application sait parfaitement qui vous êtes - vous vous êtes connecté, votre ticket est valide - mais elle oublie de se demander si vous avez le droit d'accéder à cet objet précis. Le videur a bien vérifié votre identité à l'entrée ; il vous laisse ensuite ouvrir toutes les portes de l'immeuble. L'IDOR relève ainsi de la catégorie Broken Access Control, hissée en tête du top 10 de l'OWASP, le classement de référence des failles applicatives.
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.
Le test qui révèle une IDOR
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 conclusion
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.
Vérifier vos applications et vos API
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.