Secu
Mieux sécuriser les API : un impératif confirmé par la fuite de l’ANTS
Par La rédaction, publié le 13 mai 2026
Onze millions d’identités exposées. Une simple URL trafiquée. Aucune alerte déclenchée. La fuite massive qui vient de frapper l’État français via son service ANTS n’a rien d’un exploit sophistiqué : c’est l’échec d’un contrôle élémentaire, devenu le talon d’Achille d’un numérique entièrement bâti sur les API. Et demain, sur les agents IA.
De Alessandro Fiorentino, Product Owner chez Adequacy
À la lumière de la fuite massive qui a frappé l’Agence nationale des titres sécurisés (ANTS) le 15 avril 2026, la sécurité des API apparaît plus que jamais comme un enjeu majeur de la sécurité numérique.
En exploitant une vulnérabilité d’une simplicité déconcertante, un pirate est parvenu à extraire les données personnelles de 11,7 millions d’utilisateurs du portail France Titres. Les informations compromises incluent l’identifiant de connexion, la civilité, le nom, les prénoms, l’adresse électronique, la date de naissance et l’identifiant unique du compte. À cela s’ajoutent, pour une partie des profils, l’adresse postale, le lieu de naissance ou encore le numéro de téléphone. On peut imaginer que ce complément concerne les données de personnes qui ont fait des demandes de titres que l’on réceptionne par voie postale, cartes grises permis de conduire… Autrement dit, un ensemble de données suffisamment riche pour constituer un socle d’usurpation d’identité d’une redoutable efficacité.
IDOR : quand l’autorisation devient le talon d’Achille des API
Ce qui rend cet incident particulièrement intéressant, c’est la nature même de la faille exploitée. Le pirate, se présentant sous le pseudonyme « breach3d », a utilisé une vulnérabilité IDOR (Insecure Direct Object Reference), l’une des failles les plus anciennes et les plus documentées du monde de la cybersécurité. Une vulnérabilité qui permet d’accéder aux données d’un autre utilisateur en modifiant simplement un identifiant dans une requête API, sans qu’aucun contrôle d’autorisation ne soit effectué côté serveur.
En d’autres termes, il suffisait de changer un chiffre dans l’URL pour consulter librement le profil d’un autre citoyen. Le système ne vérifiait pas si l’appelant en avait le droit. Il lui faisait confiance. Et cette confiance aveugle a suffi à exposer des millions de Français.
La vulnérabilité IDOR illustre un problème structurel : l’autorisation reste le maillon faible de la sécurité applicative. L’authentification est aujourd’hui bien maîtrisée, avec des standards robustes et largement adoptés. Mais vérifier ce que l’utilisateur a le droit de faire, et non simplement qui il est, demeure trop souvent négligé. Dans la majorité des fuites massives liées aux API, ce n’est pas l’identité de l’attaquant qui pose problème, mais l’absence de contrôle sur les ressources auxquelles il accède. L’incident de l’ANTS en est une démonstration éclatante, presque caricaturale.
Les API sont devenues la colonne vertébrale du numérique moderne. Elles orchestrent les échanges entre services, alimentent les applications mobiles, permettent l’automatisation, la scalabilité et l’interopérabilité. Mais cette omniprésence a un prix : chaque API exposée est une surface d’attaque supplémentaire. Dans les architectures distribuées actuelles, une organisation peut gérer des centaines d’API, parfois développées par des équipes différentes, avec des niveaux de maturité hétérogènes. Sans gouvernance centralisée, sans inventaire exhaustif, sans politique de sécurité cohérente, il suffit d’une seule faille logique pour compromettre l’ensemble.
De l’inventaire à la surveillance : bâtir une sécurité API continue et gouvernée
Sécuriser les API ne peut plus se résumer à ajouter une couche d’authentification ou à masquer des identifiants. Il s’agit d’un travail de fond, qui commence par une cartographie complète des interfaces exposées. On ne protège pas ce que l’on ne connaît pas. Trop d’organisations découvrent encore l’existence d’API oubliées, non maintenues ou mal configurées, parfois exposées par inadvertance. La première étape consiste donc à établir un inventaire clair, à identifier les données manipulées, les niveaux de sensibilité, les dépendances et les responsabilités.
Vient ensuite la mise en place d’un contrôle d’accès systématique et granulaire. Chaque requête doit être évaluée selon trois dimensions : qui est l’appelant, que demande-t-il, et en a-t-il réellement le droit. Cette logique doit être appliquée côté serveur, de manière centralisée, et ne jamais dépendre du client. Les modèles d’autorisation doivent être cohérents, documentés et testés. Les identifiants internes ne doivent jamais être exposés tels quels, et encore moins servir directement de clé d’accès à des données sensibles. L’utilisation d’identifiants opaques, non prédictibles, est un prérequis élémentaire.
La sécurisation des API passe également par une surveillance active. Une API qui reçoit des milliers de requêtes séquentielles visant des identifiants incrémentés doit déclencher une alerte immédiate. Dans l’affaire ANTS, l’absence de détection comportementale a permis l’aspiration massive des données sans interruption. La sécurité ne peut plus être pensée comme un dispositif statique, elle doit devenir un processus continu, capable de repérer les anomalies, de limiter les abus et de réagir en temps réel.
Enfin, la sécurité des API doit être intégrée au cycle de développement. Les équipes doivent être formées, les revues de code systématiques, les tests de sécurité intégrés aux démarches d’intégration continue et ou aux démarches de déploiement continu et les modèles de conception sécurisés adoptés dès l’amont. La faille IDOR n’est pas un bug technique complexe : c’est une erreur de logique métier. Et les erreurs de logique ne se détectent pas avec des scanners automatisés, mais avec une culture de sécurité partagée.
L’incident ANTS n’est pas seulement une fuite de données. C’est un signal d’alarme national. Il montre que la sécurité des API n’est plus un sujet technique, mais un enjeu de confiance publique. Les citoyens confient leurs données à l’État et aux entreprises avec l’idée que celles-ci seront protégées. Lorsque cette confiance est trahie, c’est l’ensemble du pacte numérique qui vacille. La question n’est plus de savoir si les organisations seront attaquées, mais si elles seront prêtes.
La sécurisation des API n’est pas un luxe. C’est une obligation. Et c’est désormais l’un des piliers essentiels de la résilience numérique.
Et ce qui est vrai aujourd’hui pour une API le sera demain pour les MCP, ces Model Context Protocols utilisés par les agents d’IA pour interagir avec des services et manipuler des données en autonomie. La moindre faille d’autorisation dans ces systèmes capables d’agir, de décider et d’orchestrer des actions à grande échelle pourrait ouvrir des brèches dont l’impact dépasserait largement celui des architectures actuelles.
À LIRE AUSSI :
À LIRE AUSSI :
