Les statistiques ne manquent pas concernant la (in)sécurité des API. Une recherche rapide sur Internet vous permettra de trouver à peu près tous les points de vue possibles sur le sujet. Il suffit de retenir que (a) les attaques visant les API sont en hausse et que (b) certaines d’entre elles aboutissent.
Il est également fréquent de constater que les organisations peinent ne serait-ce qu’à recenser toutes les API qui se cachent en leur sein. Cela ne tient pas seulement au fait que ces API sont disséminées entre le cœur du réseau, le cloud et la périphérie. C’est aussi parce qu’en dehors de la célèbre spécification OpenAPI (OAS), il n’existe pas de véritables « normes » sur lesquelles s’appuyer pour définir les API, et encore moins pour les trouver.
Cela ne signifie pas pour autant que nous en ayons besoin. Après tout, nous avons eu SOAP, WSDL et UDDI et, même si certains les utilisent encore et s’appuient toujours sur XML comme format de données, la majeure partie du monde est passée à REST, JSON, GraphQL et gRPC.
Même si nous avions des normes, cela ne changerait rien au fait que les API sont difficiles à sécuriser.
Cela s’explique par le fait que le terme API est un terme générique. Par exemple, l’API OpenTelemetry est simplement une façon de dire : « Nous mettons les fonctionnalités d’OpenTelemetry à la disposition des développeurs. » Il n’existe pas de politique de sécurité capable de couvrir « l’ »API OpenTelemetry dans son ensemble. Ce serait l’idéal et cela simplifierait grandement les choses. Mais ce n’est pas le cas. Nous disposons de politiques de sécurité qui couvrent les points de terminaison de l’API OpenTelemetry.
Examinons cela de plus près, voulez-vous ?
API et points de terminaison
Prenons l’API Open AI comme exemple, puisque tout le monde ne parle que de l’IA générative en ce moment.
La première chose que vous constaterez, c’est que même s’il n’existe qu’une « seule » API, celle-ci comporte de nombreux points de terminaison. Combien exactement ? Ce nombre évolue à chaque ajout de nouvelles fonctionnalités.
Voici une liste (non exhaustive) :
- https://api.openai.com/v1/chat/completions
- https://api.openai.com/v1/audio/speech
- https://api.openai.com/v1/audio/transcriptions
- https://api.openai.com/v1/audio/translations
- https://api.openai.com/v1/embeddings
- https://api.openai.com/v1/fine_tuning/jobs
- https://api.openai.com/v1/files
L’IA générative multimodale ajoute les médias — audio et vidéo — à la liste des types de contenu, mais nécessite également de nouveaux points de terminaison pour traiter les requêtes. Des fonctionnalités supplémentaires, telles que l’utilisation d’outils, peuvent aussi accroître le nombre de points de terminaison. Chaque avancée — chaque nouvelle capacité qui nous enthousiasme — ajoute généralement un point de terminaison supplémentaire à l’API.
Vous remarquerez également la mention « v1 » dans ces points de terminaison. Cela signifie que lorsque la v2 sortira, il faudra définir un nouvel ensemble de politiques de sécurité pour couvrir ces points de terminaison, et que certaines de ces politiques devront être adaptées en fonction des modifications apportées au point de terminaison concerné.
Cela vaut également pour la pile informatique, où l’automatisation s’effectue via les API des appareils. Le nombre de points de terminaison dépend en grande partie de votre environnement. Plus vous gérez d’appareils, plus vous devez gérer et sécuriser de points de terminaison. Et n’oublions pas que deux appareils n’utilisent jamais la même API. Ce serait insensé, n’est-ce pas ? Presque comme si deux fournisseurs de services cloud convenaient d’utiliser la même API. C’est probablement pour cette raison que la « complexité » reste le motif le plus souvent invoqué pour ne pas automatiser diverses tâches opérationnelles. La multiplication des outils et des API rend l’automatisation difficile et leur sécurisation encore plus complexe.
Mais la sécurité des API doit impérativement prendre en compte tous ces points de terminaison, car c’est par eux que les attaquants s’introduisent. Et chaque point de terminaison nécessite un ensemble différent de paramètres qui se retrouvent dans la charge utile sous forme d’objets JSON (ou XML, GraphQL ou <insérer le format ici>). Il faut définir des limites quant au contenu de chaque paramètre : est-il alphanumérique ? Peut-il contenir certains caractères ? Une plage de valeurs ? Quelle peut être sa longueur ? Quels caractères ne sont pas autorisés ? Toutes ces informations sont traduites en une politique qui impose la forme que doit prendre le contenu et empêche ainsi les attaques de passer inaperçues.
L’élaboration d’une politique pour la seule API d’OpenAI va prendre un certain temps. Et ce n’est qu’une API. D’après notre étude 2024 à paraître, les organisations disposent en moyenne de 442,8 API, et ce nombre monte en flèche dans les très grandes organisations. Quand on imagine le nombre de points de terminaison — et de versions de ces points de terminaison — que cela peut représenter, on comprend très vite pourquoi la sécurité des API est si difficile à assurer.
Et c’est pourquoi les attaquants parviennent suffisamment souvent à leurs fins pour continuer à les cibler.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
Pourquoi devriez-vous vous intéresser à WebAssembly ?
WebAssembly (Wasm) est un jeu d’instructions binaires portable, rapide et sécurisé, qui permet d’exécuter des applications hautes performances sur n’importe quelle plateforme.
Trois choses à savoir sur les applications d’IA
Les applications d’IA sont des applications modernes, mais elles présentent certaines particularités. Découvrez les points essentiels à connaître sur les applications basées sur l’IA.
État des lieux de la stratégie applicative 2022 : il est temps de moderniser les opérations
Il est devenu évident que, pour maintenir la dynamique de leur transformation numérique, les organisations doivent recentrer leurs efforts sur les fonctions métier. Si les expériences destinées aux clients restent prioritaires, il est également indispensable de permettre la numérisation de fonctions telles que les services juridiques, les ressources humaines et la finance. Les DSI prennent donc les commandes, tandis que la transformation numérique passe de la modernisation des applications à celle des opérations.
Clouds multiples ou multicloud : faciliter la transition
La gestion et la sécurisation des charges de travail deviennent complexes à mesure que les entreprises adoptent une stratégie de cloud connecté. Découvrez comment F5 répond au besoin d’une nouvelle approche de la mise en réseau multicloud.
L’expérience client dépend de la visibilité
Une enquête menée par Dimensional Research auprès de plus de 3 000 utilisateurs d’applications mobiles a confirmé ce que beaucoup d’entre nous pensent des attentes actuelles des clients.
Transformation numérique et explosion du portefeuille d’applications
La transformation numérique stimule la croissance des portefeuilles d’applications et modifie la manière dont celles-ci sont développées, déployées, intégrées et, en définitive, utilisées.