Qu’est-ce que la sécurité des API ?

Pourquoi la sécurité des API est-elle si importante ?

Les applications sont omniprésentes. Elles font désormais partie intégrante de la vie des entreprises et de la société dans son ensemble. Or, derrière presque toutes les applications se trouvent des API. Il est donc essentiel de les protéger ces interfaces efficacement.

Les API offrent un framework back-end à la plupart des applications cloud-native, dont les applications mobiles, web et SaaS, mais aussi aux applications internes ou destinées aux partenaires et aux clients. Leur utilisation est de ce fait extrêmement répandue. Pour donner une idée de l’ampleur du phénomène, la plateforme de gestion d’API Postman a, par exemple, enregistré 1,13 milliard d’appels d’API en 2022. Mais cet essor éveille aussi l’intérêt des acteurs malveillants.

Les API exposent en effet la logique des applications, les ressources et les données sensibles (y compris les données à caractère personnel). Elles sont donc devenues la cible privilégiée des attaquants, qui peuvent désormais profiter de cette porte d’entrée pour perturber le fonctionnement de l’entreprise et accéder à des informations sensibles dans le but de les exfiltrer ou de les détruire.

Approche traditionnelle de la sécurité des applications web

À l’époque des applications monolithiques, la sécurité consistait à déployer un WAF (pare-feu d’application web) en périphérie afin d’intercepter et d’inspecter le trafic HTTP envoyé par les clients. Cette approche constituait, et constitue encore, une barrière efficace pour protéger les applications contre les intrusions malveillantes via des formulaires HTTP standards ou des requêtes de navigateur.

Mais la nature des applications web a changé et le temps des monolithes hébergés par des serveurs indépendants est révolu. Nous avons désormais affaire à des objets containerisés, cloud-native et distribués dans des clusters de serveurs hôtes.

Aujourd’hui, les équipes de sécurité et les développeurs sont contraints de gérer des architectures en microservices cloud-native et distribuées dans des réseaux sans périmètre. Les applications modernes traitent par ailleurs des données provenant de sources variées (requêtes web standard, appels d’API depuis un appareil mobile, événements cloud, données de télémétrie des équipements IoT, stockage cloud, etc.).

Les requêtes HTTP entrantes (trafic nord-sud) ne représentent souvent que la première étape d’une série de flux de communication. Bien souvent, une seule requête entrante génère des dizaines d’appels d’API internes (trafic est-ouest) susceptibles d’exposer les terminaux d’API s’ils ne sont pas correctement inspectés et validés.

Malheureusement, il ne suffit pas d’inspecter le trafic entrant à la périphérie pour identifier les payloads suspects. Les terminaux d’API internes peuvent également être mal configurés et permettre à des utilisateurs non autorisés d’accéder à des microservices spécifiques, exposant ainsi la logique de l’application à des acteurs mal intentionnés. Il est donc essentiel que tous les terminaux d’API, externes ou internes, soient surveillés et protégés en permanence.

Anatomie d’une attaque d’API

Les API permettent aux entreprises de développer leurs activités, mais elles offrent aussi aux attaquants de nombreuses failles à exploiter. Cet exemple d’attaque d’API ciblant un acteur de l’e-commerce doté d’une application mobile en front-end illustre la facilité avec laquelle les cybercriminels peuvent mettre la main sur des données sensibles.

Étape 1. Grâce à un processus de rétro-ingénierie sur l’application mobile, un attaquant découvre que l’URL d’un terminal d’API utilisé pour récupérer des données à partir d’un microservice back-end est obsolète.

Étape 2. L’attaquant observe qu’aucune authentification ni autorisation n’est requise pour envoyer des appels d’API vers ce terminal.

Étape 3. L’attaquant exploite la vulnérabilité SQLi. L’URL du terminal d’API fournit un identifiant produit unique sous la forme d’une valeur numérique. Une série de tests automatisés permettent ensuite à l’attaquant de découvrir que le champ d’entrée <product_id> peut être utilisé pour lancer une attaque SQLi.

Étape 4. Plutôt que d’exploiter cette vulnérabilité SQLi pour altérer les données, l’attaquant exécute une commande shell dans le microservice qui gère la base de données SQL. Il télécharge ainsi un programme malveillant de minage de bitcoins et l’exécute.

Risques liés à la sécurité des API

Les erreurs de configuration, les failles logiques et les vulnérabilités des API mettent les applications et les données en danger. Dans ce contexte, certaines entreprises pensent s’offrir une sécurité complète en se dotant d’une passerelle API, qui se borne pourtant à surveiller le trafic acheminé via la passerelle et n’offre aucune visibilité sur le trafic interne.

Pourtant, les équipes de sécurité ont besoin d’une visibilité totale sur leur surface API, car on ne peut protéger que ce que l’on voit. Or, un acteur malveillant peut se cacher derrière chaque angle mort et chaque API fantôme.

Bien que les passerelles surveillent efficacement les API et leur utilisation, elles ne sont pas en mesure de détecter et de bloquer les attaques. La sécurité des API doit donc conjuguer visibilité, gestion des risques et protection en temps réel contre les acteurs malveillants.

Les 10 principaux risques identifiés par l’OWASP

En 2019, l’Open Web Application Security Project (OWASP) a publié la liste des 10 principaux risques liés à la sécurité des API. Le but : sensibiliser les entreprises aux menaces pesant sur les applications web. Cette liste présente les types d’attaques les plus courants visant les API web et propose des conseils pour les neutraliser.

Failles d’autorisation au niveau de l’objet

Les terminaux gérant les identifiants d’un objet sont souvent exposés. Les contrôles d’accès y sont vulnérables, ce qui étend la surface d’attaque des API. Un attaquant peut, par exemple, modifier l’identifiant d’une ressource appartenant à un autre utilisateur au cours d’un appel d’API. Grâce à cette opération, connue sous le nom d’attaque IDOR (Insecure Direct Object Reference), les acteurs malveillants peuvent accéder à des ressources auxquelles ils ne devraient pas avoir accès.

Failles d’authentification au niveau de l’utilisateur

Les mécanismes d’authentification des API constituent des cibles faciles, car ils sont exposés aux yeux de tous. Lorsqu’ils ne sont pas correctement implémentés, ils peuvent par ailleurs offrir aux attaquants une porte d’entrée dans le système et leur permettre d’usurper l’identité d’utilisateurs autorisés.

Des problèmes d’authentification peuvent survenir dès lors que les bonnes pratiques en matière de sécurité des API ne sont pas respectées. Parmi les failles courantes, on peut par exemple citer l’absence d’authentification par jeton d’accès ou l’archivage des identifiants et des clés dans les URL des terminaux d’API.

Exposition excessive des données

Plus il y a de données exposées, plus le risque est grand. Lors de l’implémentation d’une API, les développeurs exposent parfois les propriétés d’un objet sans préciser de restrictions et comptent sur le client pour filtrer les données inutiles avant qu’elles ne soient affichées dans l’interface utilisateur. Mais, même si les données sensibles sont filtrées en bout de chaîne, les attaquants peuvent toujours exploiter l’appel d’API initial pour accéder à des numéros de carte bancaire, à des identifiants de connexion ou à des numéros de sécurité sociale.

Manque de ressources et limitation du débit

Les API qui ne limitent pas le nombre de ressources pouvant être appelées par le client s’exposent à des tentatives de surcharge de trafic. Ces attaques nuisent à la performance du serveur d’API et peuvent potentiellement bloquer l’accès des utilisateurs légitimes ou même entraîner un déni de service. Or, la surcharge du serveur d’API crée des failles d’authentification que les attaquants peuvent exploiter, notamment par force brute.

Failles d’autorisation au niveau de la fonction

Les développeurs sont confrontés à des politiques de contrôle d’accès complexes, basées sur différentes hiérarchies de groupes d’utilisateurs et de rôles. Il est par ailleurs difficile de distinguer clairement les fonctions admin des fonctions non-admin. Ce manque de visibilité génère des failles d’autorisation, que les attaquants peuvent exploiter pour accéder aux ressources d’un utilisateur ou exécuter des fonctions admin non autorisées.

Assignation massive

Cette vulnérabilité apparaît lorsque les données client sont soumises à un modèle data mais ne sont pas filtrées au regard d’une liste de validation permettant d’empêcher les utilisateurs d’assigner des données à un champ protégé. Les attaquants peuvent ainsi accéder à des données sensibles en interceptant les requêtes API et en modifiant les propriétés des objets stockés en back-end. Il leur suffit pour cela de deviner les propriétés de l’objet, de lire la documentation ou de passer au crible les terminaux à la recherche d’indices sur la manière de compromettre les attributs de l’API privée.

Erreurs de configuration de sécurité

Les erreurs de configuration de sécurité peuvent déboucher sur une compromission du serveur en exposant des données utilisateurs confidentielles ou des informations système. Parmi les causes les plus courantes à l’origine de ces failles, on peut notamment citer : des politiques trop permissives de partage de ressources entre origines multiples (CORS) ; des configurations incomplètes ou ponctuelles ; des en-têtes ou méthodes HTTP incorrects ; des configurations par défaut non sécurisées et des messages d’erreurs de type verbose contenant des informations sensibles.

Injection

Les API sont exposées à des attaques par injection (injection SQL, NoSQL ou de commande), qui peuvent survenir lorsque des données non approuvées sont envoyées à un interpréteur dans le cadre d’une commande ou d’une requête. Un acteur malveillant peut ainsi amener l’interpréteur à exécuter des commandes dangereuses et à exposer des données que l’attaquant peut ensuite manipuler à sa guise ou exfiltrer.

Mauvaise gestion des assets

Les API exposent généralement plus de terminaux que les applications web traditionnelles. Il est donc essentiel de gérer efficacement ces API et de suivre chacun de ces terminaux pour empêcher tout détournement via des terminaux d’API exposés ou vulnérables. En effet, les terminaux obsolètes et de débogage, par exemple, peuvent être utilisés par des attaquants pour compromettre l’application.

Journalisation et surveillance insuffisantes

Bien qu’elles ne constituent pas une menace directe, une journalisation et une surveillance insuffisantes peuvent retarder la détection des menaces. Ce manque de vigilance laisse aux acteurs malveillants le champ libre pour mener leur attaque, s’immiscer dans différents systèmes et altérer, extraire ou détruire des données sans déclencher l’alerte. D’après plusieurs rapports d’enquête sur les compromissions, la détection d’une menace persistante peut ainsi nécessiter plus de 200 jours. Par ailleurs, sans une journalisation et une surveillance adéquates, les entreprises ne disposent pas des informations nécessaires pour évaluer les dommages subis suite à une compromission de données.

Sécurité des API pour SOAP, REST et GraphQL

Les trois modèles d’architecture d’API les plus courants sont SOAP, REST et GraphQL. Chacun d’entre eux présente des enjeux de sécurité spécifiques.

Sécurité des API SOAP

SOAP (Simple Object Access Protocol) est un protocole d’échange de données structurées permettant d’implémenter des services web dans des réseaux informatiques. Il communique en langage XML et peut être acheminé par différents protocoles de niveau inférieur, tels que HTTP ou SMTP. Les API SOAP sont généralement protégées par différentes mesures de sécurité appliquées au niveau de la couche de transport (comme HTTPS) et du message (signatures numériques et chiffrement XML, etc.).

La sécurité de ces API passe par des extensions de protocoles permettant de gérer les incidents. Le protocole SOAP suit les spécifications Web Services (WS), qui assurent la sécurité de tous les services web de l’entreprise grâce à des fonctionnalités comme WS-ReliableMessaging, conçue pour étendre la prise en charge intégrée des erreurs.

Sécurité des API REST

Les API REST (Representational State Transfer) sont basées sur le transfert de données JSON et le protocole HTTP/S. Elles se révèlent donc souvent plus simples à développer que d’autres architectures d’API. Les API RESTful utilisent quant à elles des requêtes HTTP pour créer (POST), mettre à jour (PUT), lire (GET) et supprimer (DELETE) des données.

En l’absence de politiques de protection intégrées, la sécurité des API REST dépend uniquement de leur conception. Il est donc important que les services de transmission, de déploiement et d’interaction avec le client intègrent des mesures de sécurité adaptées. De leur côté, la plupart des API RESTful s’appuient des dispositifs de sécurité appliqués au niveau de la couche de transport (par ex. HTTPS) et sur l’authentification par jeton.

Pour assurer leur sécurité, les API REST sont souvent déployées derrière une passerelle, via laquelle les clients pourront choisir de se connecter. Il faut toutefois garder à l’esprit que les passerelles API ne protègent pas l’architecture de l’ensemble des menaces.

REST vs SOAP

Les API SOAP et RESTful prennent toutes deux en charge les requêtes et les réponses transmises via des protocoles HTTP et SSL (Secure Sockets Layer), mais leurs similitudes s’arrêtent là. Avec leurs fonctionnalités de sécurité intégrées, les API SOAP sont intrinsèquement sûres. Les API RESTful, en revanche, doivent être protégées par des choix d’implémentation et d’architecture adaptés.

Sécurité des API GraphQL

GraphQL est un langage API open-source qui 1) décrit la manière dont les clients demandent des informations et 2) agit comme un environnement d’exécution permettant de traiter des requêtes avec des données existantes. Sa syntaxe est utilisée par les développeurs pour effectuer des demandes de données spécifiques provenant d’une ou plusieurs sources. Elle permet par ailleurs aux clients de définir la structure des données devant être renvoyées par le serveur.

La sécurité des API GraphQL se heurte donc à des difficultés liées à la personnalisation et à la flexibilité des requêtes. Le serveur pourrait en effet être dans l’incapacité de traiter des demandes complexes et exécuter, par inadvertance, des requêtes malveillantes au cours du processus.

Pour atténuer les risques et éviter les requêtes volumineuses, il est toutefois possible de limiter le nombre ainsi que la profondeur des requêtes et de définir un délai d’expiration.

Les bonnes pratiques pour la sécurité des API

Les API sont de plus en plus répandues et accessibles. Il est donc important de limiter les risques d’exposition des données en appliquant les bonnes pratiques permettant de réduire la surface d’attaque, de corriger les vulnérabilités et de lutter contre les menaces en temps quasi réel.

Méthodes d’authentification et d’autorisation sécurisées

Limitez l’accès des API aux utilisateurs autorisés grâce à des méthodes d’authentification sécurisées, comme OAuth2 ou les jetons web JSON (JWT).

Limite de débit

Limitez le débit de vos API pour bloquer les comportements malveillants, par exemple les attaques par force brute. Cette approche vous permet de restreindre le nombre de requêtes pouvant être adressé à une API au cours d’une période donnée.

Protocole HTTPS

Utilisez le protocole HTTPS pour garantir le chiffrement et la sécurité des requêtes et des réponses de l’API. Cette bonne pratique se révèle particulièrement importante pour protéger les données sensibles.

Évaluations régulières de la sécurité

Évaluez régulièrement la sécurité de vos API pour identifier les failles potentielles. Il est également conseillé de passer en revue les changements apportés à l’inventaire des API. Vous pourrez ainsi détecter les API récemment exposées et définir leur profil de risque, notamment en ce qui concerne l’exposition des données sensibles, l’exposition aux menaces web, les vulnérabilités des workloads et le niveau d’authentification.

Clé API

Une clé API est un identifiant unique utilisé pour reconnaître l’application appelant une API et vérifier son autorisation d’accès. Contrairement aux jetons d’authentification (qui identifient l’utilisateur), la clé API identifie directement l’application ou le site web à l’origine de l’appel. Les deux mesures sont donc complémentaires.

Stocker les clés API de manière appropriée vous permettra ainsi d’éviter les appels indésirables, de bloquer les accès non autorisés et de protéger vos données confidentielles contre les compromissions et les pertes.

Surveillance des API

Gérez et surveillez les spécifications, la documentation, les scénarios de test, le trafic et les métriques de vos API. Cette approche vous permet de bloquer les activités indésirables, comme le trafic et les bots malveillants, pour protéger vos applications tout en réduisant les coûts.

Sensibilisation des équipes aux bonnes pratiques

Sécurisez vos pipelines CI/CD en amont et sensibilisez vos développeurs aux risques, comme les failles d’authentification et les vulnérabilités logiques. Il est également recommandé de mettre en œuvre les principes DevSecOps , notamment en ce qui concerne la collaboration entre les équipes de sécurité et de développement.

Identification des vulnérabilités

Identifiez vos vulnérabilités au regard des 10 principaux risques API identifiés par l’OWASP. Une analyse régulière de vos API à l’aide d’outils et de techniques appropriés vous permettra de repérer et de combler immédiatement les failles dans lesquelles les attaquants pourraient s’engouffrer.

Authentification par jeton

L’authentification par jeton constitue votre première ligne de défense. Cette approche protège en effet les API contre les accès non autorisés en rejetant les appels des utilisateurs ne disposant pas d’un jeton valide.

Pour résumer, les bonnes pratiques de la sécurité API exigent une visibilité étendue et une surveillance efficace de la surface d’attaque. Ces dernières passent par une identification automatique de toutes les applications web et de tous les terminaux d’API au sein de votre environnement. Les couches de défense devraient par ailleurs inclure des politiques régissant le trafic nord-sud et est-ouest afin de bloquer aussi bien les menaces venant d’Internet que des applications elles-mêmes.

Pour renforcer la sécurité de vos applications, vous pouvez également ajouter une autre couche d’analyse des vulnérabilités et de la conformité ainsi qu’une authentification forte. Vous devrez aussi sécuriser vos workloads ou votre couche d’infrastructure (hôtes, VM, containers et systèmes sans serveur hébergeant vos applications).

Solution de sécurité API Prisma Cloud

Détection des API, profilage des risques, protection en temps réel de toutes les API… la plateforme de protection des applications cloud-native (CNAPP) de Prisma Cloudoffre une solution de sécurité complète.

Fonctionnalités de sécurité API

• Détection des API – Détectez automatiquement toutes les API de votre environnement et éliminez les angles morts causés par les API fantômes ou non autorisées.
• Profilage des risques associés aux API – Identifiez les risques ainsi que les facteurs de risque associés aux API (erreurs de configuration, exposition des données sensibles, contrôle d’accès, etc.) et priorisez vos efforts de remédiation.
• Protection en temps réel – Appliquez des mesures de protection en temps réel pour lutter contre la surcharge de trafic, les bots malveillants et les 10 principaux risques identifiés par l’OWASP.

Sécurité des API : questions fréquentes