Failles IDOR : de l’ANTS à ÉduConnect, un risque systémique pour les DSI
De l’ANTS à ÉduConnect : la faille IDOR devient un risque systémique
La faille IDOR sécurité applications web est sortie de la théorie pour frapper le cœur de l’État français. Quand l’Agence nationale des titres sécurisés a confirmé l’exposition de 11,7 millions de comptes (communiqué ANTS du 13 février 2024, repris le même jour par la CNIL et plusieurs CERT nationaux dans leurs bulletins d’alerte), la vulnérabilité d’autorisation n’était plus un scénario de pentester mais un risque macro pour toute DSI. Cette même logique d’IDOR, où un identifiant d’objet manipulé dans une URL ou une API permet d’accéder à des données d’un autre utilisateur, a ensuite été retrouvée chez ÉduConnect, les CROUS, AlumnForce et la Fédération française de rugby, selon les analyses publiées par i‑Lead Consulting et le site donneespersonnelles.fr entre décembre 2023 et avril 2024.
Une courte chronologie illustre ce glissement vers un risque systémique : fin 2023, premiers signalements de références d’objets prévisibles sur des portails étudiants (rapports i‑Lead datés de novembre et décembre 2023) ; janvier 2024, découverte d’un IDOR sur ÉduConnect permettant de consulter les données d’élèves via un simple incrément d’identifiant, documenté dans plusieurs tickets CERT et articles spécialisés ; février 2024, confirmation par l’ANTS de l’incident touchant 11,7 millions de comptes dans son communiqué officiel du 13/02/2024 ; printemps 2024, publication par donneespersonnelles.fr de plusieurs preuves de concept minimales sur des espaces en ligne de fédérations sportives et de plateformes d’anciens élèves, avec des captures datées et horodatées.
Dans tous ces cas, les attaquants ont exploité des références d’objets prévisibles ou non protégées, transformant chaque référence d’objet en « insecure object » et chaque identifiant en sésame pour des données personnelles massives. Concrètement, un simple changement d’ID numérique dans un paramètre web suffisait, par exemple, à afficher la fiche d’un autre étudiant ou le profil d’un autre licencié sportif. Les failles IDOR ont ainsi permis de parcourir des références d’objets séquentielles, de casser le contrôle d’access control logique et de contourner le level authorization attendu pour un utilisateur authentifié standard. Pour un directeur des systèmes d’information, ces vulnérabilités IDOR révèlent un défaut de sécurité web structurel, bien au‑delà d’une simple erreur de développement isolée, et rejoignent les constats formulés dans les analyses de DSI Market sur la gestion des risques en cybersécurité.
Les chiffres publiés par i‑Lead Consulting et le site donneespersonnelles.fr montrent une même signature technique : une application web ou plusieurs applications web exposant des identifiants dans des paramètres web, des API sans référence sécurisée, et un broken access control non détecté par les outils classiques. Les rapports de ces acteurs détaillent par exemple des endpoints REST renvoyant des données d’un autre compte après simple modification d’un identifiant incrémental, sans aucun contrôle d’appartenance. La répétition des failles IDOR dans ces applications publiques illustre un angle mort de la sécurité des applications, où l’on protège le périmètre mais pas les objets métiers eux‑mêmes. Pour les grandes organisations, la question n’est plus de savoir si une vulnérabilité IDOR existe, mais dans combien d’applications et d’API partenaires elle se cache déjà, y compris dans les services exposés décrits dans les travaux sur l’architecture de sécurité des systèmes d’information.
Pourquoi les scans WAF et DAST laissent passer les failles IDOR
Les DSI qui s’appuient principalement sur un WAF et quelques campagnes DAST pour sécuriser leurs applications web sous‑estiment la nature logique de la faille IDOR. Un pare‑feu applicatif filtrera les injections et les patterns connus, mais il ne comprend pas que la référence d’un objet client ne doit pas être accessible à un autre utilisateur authentifié, même si la requête semble techniquement valide. Les tests de sécurité automatisés se concentrent sur les signatures OWASP classiques, alors que les vulnérabilités IDOR relèvent d’un mauvais design d’autorisation et de références objets, souvent propre à chaque application métier et à ses règles d’accès internes.
Dans les référentiels OWASP, la catégorie « broken access control » couvre précisément ces failles d’autorisation, mais les outils DAST peinent à simuler des scénarios multi‑comptes avec des identifiants et des références variés. Une API REST peut ainsi exposer un endpoint parfaitement conforme aux bonnes pratiques OWASP API en apparence, tout en laissant un attaquant modifier un identifiant numérique pour accéder à des données d’un autre utilisateur. Un scénario typique observé par les équipes de réponse à incident consiste à :
- capturer une requête légitime d’un utilisateur authentifié vers une ressource métier (profil, dossier, contrat) ;
- remplacer l’identifiant de l’objet par un autre ID séquentiel ou facilement devinable ;
- constater que l’API renvoie les données d’un tiers sans déclencher d’alerte ni de refus d’accès.
Un exemple minimal de contrôle côté serveur illustre la différence : avant de retourner une ressource, l’API doit vérifier que resource.ownerId == currentUser.id et refuser l’accès si cette condition échoue, même si le jeton d’authentification est valide. Dans un pipeline CI/CD, un test d’acceptation IDOR peut être considéré comme réussi si, pour au moins deux comptes de test distincts, toute tentative de requête croisée (compte A accédant à l’objet du compte B via un simple changement d’ID) renvoie systématiquement un code HTTP 403 ou 404, sans fuite de données dans la réponse.
Les retours de terrain de Wavestone, d’Orange Cyberdéfense ou de la cellule CERT de BNP Paribas convergent : plus de la moitié des vulnérabilités IDOR critiques sont détectées par des tests manuels scénarisés, et non par les scanners. Ces acteurs décrivent des campagnes où les consultants rejouent des parcours utilisateurs complets avec plusieurs profils, en variant systématiquement les identifiants d’objets dans les URL et les appels API. Pour un CIO, cela impose de revoir la stratégie de sécurité web en intégrant des parcours fonctionnels complets, avec plusieurs profils d’utilisateurs et plusieurs niveaux d’autorisation, plutôt que de se reposer sur des scores de conformité génériques. Un programme de gestion des risques en cybersécurité réellement efficace passe par une priorisation des cas d’usage métier, comme le détaille l’analyse sur l’optimisation de la gestion des risques en cybersécurité proposée par DSI Market et les recommandations associées pour les DSI.
Repenser l’architecture d’autorisation et la gouvernance applicative côté DSI
Pour sortir de cette vulnérabilité systémique, la réponse ne peut pas se limiter à un nouveau test de sécurité ponctuel ou à un audit OWASP supplémentaire. Les DSI de groupes comme SNCF, Crédit Agricole ou Airbus ont commencé à industrialiser une couche d’access control centralisée, avec des références sécurisées et des objets métiers abstraits, plutôt que de laisser chaque application web gérer ses propres identifiants. Cette approche réduit mécaniquement la surface de failles IDOR en supprimant les références directes aux objets sensibles dans les URL et les paramètres d’API, et en imposant des contrôles d’autorisation homogènes sur l’ensemble du système d’information, conformément aux principes décrits dans les travaux sur les enjeux de l’architecture de sécurité des systèmes d’information.
Concrètement, cela signifie imposer des jetons opaques au lieu d’identifiants séquentiels, encapsuler chaque référence d’objet dans une couche de sécurisation, et vérifier systématiquement que l’utilisateur authentifié dispose bien du bon level authorization pour chaque action. Pour les DSI, les principaux leviers de mitigation opérationnelle sont :
- remplacer les identifiants métiers exposés par des références techniques non prédictibles (UUID, tokens chiffrés) et documenter cette exigence dans les standards internes ;
- implémenter des contrôles d’appartenance systématiques côté serveur sur chaque ressource sensible, avec des règles d’autorisation testées automatiquement en intégration continue ;
- intégrer des tests IDOR dédiés dans les pipelines CI/CD et les revues de code applicatif, avec des critères de succès mesurables (taux de couverture des endpoints critiques, absence de réponse 200 sur des requêtes croisées entre comptes de test).
Les architectures inspirées des frameworks NIST et ISO 27001, combinées à une gouvernance forte de la sécurité des applications, permettent de traiter les vulnérabilités IDOR comme un risque de conception et non comme un simple bug. La loi Résilience et la transposition de NIS2 vont d’ailleurs pousser les DSI français à documenter beaucoup plus finement leurs contrôles d’autorisation, comme l’explique l’analyse dédiée aux exigences de la directive pour les DSI et les impacts sur la gouvernance SSI.
Sur le plan opérationnel, la clé reste la collaboration entre les équipes de développement, les RSSI et les architectes, avec des revues de conception centrées sur les objets métiers et les références objets. Les responsables informatiques qui pilotent déjà une architecture SSI structurée, telle que décrite dans les travaux sur les enjeux de l’architecture de sécurité des systèmes d’information, disposent d’un avantage net pour intégrer ces contrôles d’autorisation dès la phase de design. Au final, la vraie métrique n’est pas le nombre de slides sur le broken access control, mais le nombre de tickets d’incident IDOR que vous n’aurez jamais à ouvrir le lundi matin, grâce à une stratégie de cybersécurité pilotée par les risques et ancrée dans les pratiques de développement quotidiennes.