Trois éléments essentiels que chaque RSSI doit connaître sur la sécurité des API

Dans le troisième épisode du F5 Global CISO : Par des défenseurs, pour des défenseurs, j’ai eu le plaisir d’accueillir Corey Ball, l’un de mes experts favoris en piratage d’API. Depuis 15 ans, Corey travaille dans l’informatique et la cybersécurité. Il a même écrit un livre sur le piratage des API, après avoir constaté qu’il manquait une véritable source d’expertise centralisée sur le sujet. C’est à ce moment-là que nous nous sommes rencontrés.

Le livre s’intitule Hacking APIs : Breaking Web Application Programming Interfaces, qui vous offre une formation accélérée sur les tests de sécurité des API web. Corey a aussi cofondé APIsec University, une ressource gratuite pour maîtriser la sécurité des API, et il est fondateur et PDG de hAPI Labs, spécialisé dans les tests de sécurité des API et les tests de pénétration des applications web.

Corey est indéniablement un expert en sécurité des API, alors je lui ai posé la question du jour : Quelles sont les trois choses essentielles que chaque RSSI doit connaître sur la sécurité des API ? Je voulais notamment savoir ce que les défenseurs pourraient apprendre en adoptant le point de vue des attaquants sur la sécurité des API.

Les API constituent la technologie qui permet le transfert des données, l'une des ressources les plus précieuses au monde. « Même si nous protégeons ces données avec des pare-feu et des pare-feu d’applications web », explique Corey, « les API exposées sur Internet restent souvent des points d’entrée fragiles. » Lorsqu’une API n’est pas sécurisée, sans authentification ni contrôle d’autorisation, elle ouvre directement la voie à un attaquant, prêt à faire des requêtes non autorisées et à voler les données pourtant protégées par toutes ces défenses.

« Je veux que les défenseurs comprennent qu’ils doivent utiliser les bons outils et méthodes pour tester la sécurité de leurs API », a-t-il affirmé. Il ne suffit pas de lancer un scanner automatisé sur une API, d’obtenir un rapport sans défaut et de supposer que tout est sécurisé. Vous devez tester et analyser activement les requêtes API pour détecter les problèmes réels et corriger toutes les vulnérabilités existantes.

Tester vos testeurs. Corey suggère de valider les compétences et outils de test en pratiquant sur des applications volontairement vulnérables, des cibles sûres conçues pour permettre aux testeurs d’expérimenter, reproduire et comprendre les problèmes courants de sécurité des API. « Par exemple, le projet OWASP API Security propose crAPI, un outil de formation intentionnellement truffé de vulnérabilités API, conçu pour enseigner, apprendre et s’entraîner à la sécurité des API. Vous pouvez envoyer votre scanner directement sur crAPI pour analyser les résultats obtenus. » Si vous ne détectez que des vulnérabilités superficielles, comme des en-têtes HSTS absents ou des protections contre le clickjacking mal configurées, votre outil de test risque de passer à côté de failles API bien plus critiques, notamment celles répertoriées dans le Top 10 API OWASP.  « Cela prouverait que vos outils de test ne sont pas aussi performants que vous le croyez », explique Corey.

Corey et moi avons aussi constaté que les outils classiques de gestion des vulnérabilités en entreprise ne conviennent pas aux API, car les attaques visent des failles différentes de celles ciblant les applications web traditionnelles. Par exemple, l’autorisation défaillante au niveau des objets (BOLA) et celle au niveau des propriétés d’objet (BOPLA) sont des faiblesses spécifiques d’API liées à la logique métier essentielle. J’ai demandé à Corey : si une entreprise a déjà déployé un WAF et une passerelle API, qu’est-ce qui manque à sa protection des API ?

Les WAF et les passerelles API jouent un rôle essentiel dans la sécurité des applications et l’authentification des utilisateurs, mais ils ne suffisent pas à protéger les API. Le plus grand défi pour sécuriser les API réside dans l’autorisation : garantir que vous ne puissiez accéder qu’à vos propres données, les voir, les modifier ou les supprimer. « Vous devez vous assurer que l’utilisateur A n’interagit qu’avec les ressources qui lui appartiennent. Il ne peut pas modifier, lire, mettre à jour ou supprimer les ressources de l’utilisateur B », explique-t-il. « L’autorisation dans les API représente clairement un défi complexe. Une requête malveillante visant les ressources d’un autre utilisateur ressemblera beaucoup à une requête valide, sauf si des règles d’autorisation très précises sont mises en place. »

Vous devez intégrer les contrôles d’autorisation dans une approche multicouche de la sécurité des API, en combinant plusieurs contrôles complémentaires pour que si une couche cède, les autres continuent de vous protéger.

Alors que vous investissez de plus en plus dans l’IA générative et les applications propulsées par l’IA, sachez que ces technologies élargissent la surface d’attaque des API. En effet, les applications d’IA générative s’appuient entièrement sur des API. Autrement dit, un monde dominé par l’IA est également un monde de l’API ; la structure fondamentale des applications d’IA générative repose largement sur ces interfaces, qui exposent presque chaque composant du système d’IA.

Mais, comme l’a dit Corey et moi, les API représentent seulement une partie du défi que vous rencontrez pour sécuriser les applications et architectures basées sur l’IA : Les moteurs d’IA et les grands modèles de langage (LLM) exposent aussi d’autres vulnérabilités exploitables. Par exemple, le Model Context Protocol (MCP) est une norme open source qui établit un cadre unique permettant de connecter les LLM à des outils et services externes. Bien que les MCP facilitent l’intégration de l’IA dans vos applications, ils génèrent en même temps d’importants défis de sécurité. « En regardant dans les coulisses de l’IA générative », explique Corey, « il s’agit déjà d’une multitude d’API, auxquelles s’ajoutent les MCP, souvent vulnérables à cause de contrôles d’authentification et d’autorisation fragiles—même si les protections de sécurité évoluent rapidement. »

Une autre question de sécurité des MCP concerne les attaques par injection de requêtes et le piratage en langage naturel. « Ces risques apparaissent lorsque vos agents IA et chatbots représentent votre entreprise. Des attaquants peuvent détourner vos agents IA pour qu’ils prononcent des propos inappropriés qui nuisent à votre image, ou pousser les chatbots à octroyer des remises non autorisées. » Les organisations doivent aussi garder à l’esprit que les chatbots peuvent être considérés comme des représentants légaux de l’entreprise et en répondre juridiquement. Vous devez rester vigilants : vous ne voulez pas manquer les opportunités offertes par les applications IA, mais vous devez vous assurer qu’elles s’appuient sur des données fiables et qu’elles sont protégées contre les injections de requêtes.

C’est toujours un plaisir de discuter avec Corey, et je tiens à le remercier de m’avoir rejoint pour échanger sur ce que les défenseurs peuvent apprendre en analysant la sécurité du point de vue de l’attaquant. En tant que défenseurs, nous devons nous appuyer sur les méthodes offensives. Il est essentiel que vous compreniez comment les attaquants agissent et ce qu’ils ciblent, afin d’allouer judicieusement vos ressources limitées dans une défense multilayer cohérente, adaptée à votre entreprise, ministère ou agence.