Dans le troisième épisode de F5 Global CISO: Pour les défenseurs, par les défenseurs, j’ai reçu Corey Ball, l’un de mes hackers d’API préférés. Corey travaille dans l’informatique et la cybersécurité depuis 15 ans. Il a littéralement écrit le livre de référence sur le piratage des API après avoir constaté qu’il n’existait pratiquement aucune compilation de connaissances sur le sujet. C’est à cette occasion que nous nous sommes rencontrés.
Le livre s’intitule « Hacking APIs: Breaking Web Application Programming Interfaces, » et propose un cours intensif sur les tests de sécurité des API web. Corey a également cofondé APIsec University, une ressource gratuite pour se former à la sécurité des API, et est le fondateur et PDG de hAPI Labs, qui réalise des tests de sécurité des API et des tests d’intrusion sur les applications web.
Écouter maintenant
Découvrez les derniers épisodes de mon podcast:
Corey est manifestement un expert de la sécurité des API. Je lui ai donc posé la question du jour : quelles sont les trois choses que tout RSSI devrait savoir sur la sécurité des API ? Je voulais notamment connaître son avis sur les enseignements que les défenseurs pourraient tirer d’une analyse de la sécurité des API du point de vue de l’attaquant.
Conseil n° 1 : testez vos outils de test de la sécurité des API
Les API sont la technologie qui permet le transfert des données, l’une des ressources les plus précieuses au monde. « Mais même si nous mettons en place plusieurs couches de défense, comme des pare-feu et des pare-feu d’applications web, pour protéger ces données, explique Corey, les API accessibles depuis Internet peuvent souvent constituer une porte d’entrée pour une attaque. » Une API non sécurisée qui n’exige aucune authentification ou n’applique aucun contrôle des autorisations peut offrir un accès direct à un cybercriminel, qui peut alors envoyer des requêtes non autorisées et dérober les données pourtant protégées par toutes ces autres couches de sécurité.
« Je veux m’assurer que les équipes de défense comprennent qu’elles doivent utiliser les outils et les approches appropriés pour tester la sécurité de leurs API », a-t-il déclaré. Il ne suffit pas de lancer un scanner automatisé sur une API, d’obtenir un rapport ne signalant aucun problème et de supposer que tout est sécurisé. Les équipes de défense doivent tester et analyser activement les requêtes API afin de détecter les problèmes réels et de corriger toutes les failles de sécurité existantes.
Tester vos testeurs. Selon Corey, un moyen concret de valider les compétences et les outils de test consiste à s’exercer sur des applications volontairement vulnérables. Il s’agit de cibles sûres, spécialement conçues pour permettre aux testeurs d’expérimenter, de reproduire et de comprendre les types courants de problèmes de sécurité des API. « Par exemple, l’OWASP API Security Project propose crAPI, un outil de formation délibérément truffé de vulnérabilités d’API et conçu pour enseigner, apprendre et mettre en pratique la sécurité des API. Vous pouvez lancer votre scanner directement sur crAPI et voir quels résultats vous obtenez. » Si seules des vulnérabilités superficielles sont détectées, comme l’absence d’en-têtes HSTS ou une mauvaise configuration des protections contre le détournement de clic, votre outil de test risque de passer à côté de vulnérabilités d’API plus graves, telles que celles figurant dans le Top 10 des risques de sécurité des API de l’OWASP. « Cela montrerait que vos outils de test ne sont peut-être pas aussi efficaces que vous le pensez », a déclaré Corey.
Conseil n° 2 : les WAF et les passerelles API ne suffisent pas à protéger les API
Corey et moi avons également évoqué le fait que les outils classiques de gestion des vulnérabilités et les programmes de gestion des entreprises ne sont pas adaptés aux API, car celles-ci sont exposées à des types d’attaques différents de ceux qui ciblent les applications web traditionnelles. Par exemple, les failles d’autorisation au niveau des objets (BOLA) et des propriétés des objets (BOPLA) sont des vulnérabilités de sécurité propres aux API, liées à leur logique métier fondamentale. J’ai demandé à Corey ce qui manquait à une entreprise ayant déployé un WAF et une passerelle API pour protéger ses API.
Les WAF et les passerelles API sont essentiels à la sécurité des applications et à l’authentification des utilisateurs, a-t-il expliqué, mais ils ne suffisent pas à eux seuls à protéger les API. Le principal défi en matière de sécurisation des API réside dans l’autorisation, qui consiste à s’assurer que les utilisateurs peuvent uniquement accéder à leurs propres données, les consulter, les modifier ou les supprimer. « Vous devez vous assurer que l’utilisateur A ne peut interagir qu’avec les ressources de l’utilisateur A. Il ne doit pas pouvoir modifier, consulter, mettre à jour ou supprimer les ressources de l’utilisateur B », a-t-il déclaré. « La gestion des autorisations dans les API est particulièrement complexe. La requête d’un cybercriminel visant à accéder aux ressources d’un tiers ressemblera beaucoup à une requête légitime, à moins que des règles d’autorisation précises ne soient en place. »
Les contrôles d’autorisation doivent s’inscrire dans une approche multicouche de la sécurité des API, combinant plusieurs contrôles complémentaires afin que, si une couche échoue, les autres continuent d’assurer une protection.
Conseil n° 3 : la sécurisation de l’IA générative exige des protections supplémentaires
À mesure que les organisations investissent davantage dans l’IA générative et les applications basées sur l’IA, elles doivent comprendre que ces technologies élargissent la surface d’attaque des API. En effet, les applications d’IA générative reposent entièrement sur des API. Autrement dit, le monde de l’IA est un monde d’API : l’architecture sous-jacente des applications d’IA générative dépend fortement des API, et presque toutes les composantes du système d’IA sont exposées par l’intermédiaire de ces interfaces.
Mais, comme Corey et moi l’avons évoqué, les API ne représentent qu’une partie des défis liés à la sécurisation des applications et des architectures d’IA : les moteurs d’IA et les grands modèles de langage (LLM) présentent eux aussi d’autres vulnérabilités susceptibles d’être exploitées. Par exemple, le protocole Model Context Protocol (MCP) est une norme open source qui fournit un cadre unifié permettant de connecter les LLM à des outils et services externes. Si les MCP offrent de nombreux avantages pour intégrer l’IA aux applications, ils posent également d’importants problèmes de sécurité. « Lorsqu’on examine les coulisses de l’IA générative, explique Corey, on constate qu’elle repose déjà sur une multitude d’API, auxquelles viennent ensuite s’ajouter les MCP, souvent vulnérables en raison de contrôles d’authentification et d’autorisation insuffisants — même si les dispositifs de sécurité rattrapent leur retard. »
Les attaques par injection de prompts et le piratage en langage naturel constituent un autre enjeu de sécurité lié aux MCP. « Ils peuvent engendrer des risques pour l’entreprise lorsque des agents d’IA et des chatbots la représentent. Des attaquants peuvent manipuler vos agents d’IA pour leur faire tenir des propos déplacés qui nuisent à l’image de votre entreprise, ou convaincre des chatbots d’accorder des remises non autorisées. » Les organisations doivent également comprendre que les chatbots peuvent être considérés comme des représentants légaux de l’entreprise, laquelle peut être tenue juridiquement responsable de leurs déclarations et de leurs actions. Les entreprises doivent faire preuve de prudence : elles ne veulent pas passer à côté des opportunités commerciales offertes par les applications d’IA, mais elles doivent aussi exercer la diligence requise pour s’assurer que les applications d’IA et les chatbots sont entraînés à partir de données fiables et protégés contre les injections de prompts.
C’est toujours un plaisir d’échanger avec Corey, et je tiens à le remercier de s’être joint à moi pour discuter de ce que les défenseurs peuvent apprendre en envisageant la sécurité du point de vue de l’attaquant. En tant que défenseurs, nous devons adapter notre défense aux méthodes offensives. Nous devons donc tous comprendre le fonctionnement de l’offensive et ce que recherchent ces opérateurs, afin de pouvoir affecter judicieusement nos ressources limitées à une défense multicouche adaptée à votre entreprise, votre ministère ou votre organisme.
Votre source incontournable pour garder une longueur d’avance sur les menaces
Vous pouvez retrouver l’intégralité de mon entretien avec Corey Ball ici.
Abonnez-vous dès maintenant pour retrouver tous les épisodes de The Global CISO : par des défenseurs, pour des défenseurs sur la plateforme de podcasts de votre choix, et partagez-les avec votre équipe, vos pairs et votre réseau.
Et comme toujours, si vous souhaitez que certains sujets soient abordés, n’hésitez pas à m’envoyer un message ou à me contacter sur LinkedIn.
À propos de l’auteur
Articles de blog associés
F5 rejoint le projet PQC du NIST pour contribuer à l’élaboration de normes résistantes aux attaques quantiques
En rejoignant le consortium du projet « Migration to PQC » du NIST, F5 contribue à élaborer des recommandations pratiques pour un monde résistant aux menaces quantiques.
La dernière version de F5 Distributed Cloud Bot Defense offre des fonctionnalités et des améliorations de nouvelle génération
Les mises à jour de la console de F5 Distributed Cloud Bot Defense améliorent la gestion des menaces automatisées et l’intégration dans des cadres de sécurité plus larges.
La nouvelle surface de risque liée à l’IA : invisible, autonome et déjà à l’intérieur
James White, vice-président de l’ingénierie chez F5 À mi-parcours de l’année 2025, le moment est bien choisi pour dresser un état des lieux de l’adoption de l’IA en entreprise et de la sécurité de l’IA. L’utilisation de l’IA générative est désormais la norme dans les entreprises De manière générale, les entreprises possèdent au moins une compréhension élémentaire de l’IA générative. Elles savent ce qu’elle est et où elle peut […]
Évaluation des LLM : renforcer la confiance grâce à la notation de sécurité
À mesure que l’adoption de l’IA s’accélère dans les entreprises, l’évaluation des LLM ne porte plus uniquement sur leurs performances, mais aussi sur la confiance qu’ils inspirent. Les équipes de sécurité doivent évaluer non seulement les performances d’un modèle, mais aussi la sûreté de son comportement. Pourtant, la plupart des cadres d’évaluation se concentrent sur des critères de précision, laissant les facteurs de sécurité et de risque dans le flou ou sans mesure.
Évaluer le niveau de préparation de votre organisation à la sécurité de l’IA
Dans un paysage de l’intelligence artificielle (IA) en constante évolution, il est non seulement important, mais impératif de savoir si votre organisation est prête à instaurer et à soutenir une culture de la sécurité de l’IA. À mesure que les technologies d’IA progressent, elles font émerger une multitude de nouveaux défis de sécurité qui, pour être gérés efficacement, exigent une approche réfléchie, globale et proactive […]
Déployer des LLM en entreprise : via une API dans un cloud privé
Pris isolément, sans mesures de protection spécialisées ni protocoles de sécurité en place, le déploiement de modèles d’IA générative (GenAI), en particulier de grands modèles de langage (LLM), à l’échelle de l’entreprise représente pour toute organisation une opportunité à haut risque, mais potentiellement très rentable. La manière précise dont votre organisation doit franchir ce grand pas dans l’univers de la GenAI nécessite une planification mûrement réfléchie. Peut-être serait-il […]