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

Aperçu

Les interfaces de programmation d’applications, ou API, jouent un rôle essentiel en permettant aux applications logicielles de communiquer entre elles. Mais elles peuvent aussi devenir des vecteurs d’attaque. Lorsqu’une API ne dispose pas de protections de sécurité telles que des contrôles d’accès efficaces ou une validation des entrées, les acteurs malveillants peuvent l’utiliser à mauvais escient pour exfiltrer des données sensibles d’une application, manipuler le comportement de l’application ou perturber des services essentiels.

La sécurité des API atténue ces risques. En respectant les principes de sécurité des API à tous les stades du cycle de vie des API, par exemple en intégrant des contrôles de sécurité dans les API lors de la phase de design, en évaluant soigneusement les risques de sécurité des API lors des tests et en surveillant les attaques des API en production, les entreprises peuvent minimiser les risques que les API deviennent le maillon le plus faible de leur dispositif de sécurité.

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

La sécurité des API consiste à minimiser les risques de sécurité associés aux interfaces de programmation d’applications (API).

Pour bien comprendre la définition de la sécurité des API, il est utile de comprendre le fonctionnement des API. Une API est un mécanisme qui permet à deux ou plusieurs applications d’échanger des données. Les API fonctionnent en définissant un ensemble de règles qui déterminent comment une application doit formater les données et les envoyer à une autre application. Elles définissent également la manière dont l’application réceptrice peut renvoyer une réponse à l’application d’origine.

Si les API jouent un rôle légitime et crucial en permettant aux applications de communiquer facilement entre elles, elles peuvent également devenir un vecteur d’attaque. Les acteurs malveillants pourraient utiliser une API pour envoyer une requête malveillante à une application, par exemple. Par ailleurs, ils pourraient exploiter une API dépourvue de contrôles d’authentification pour demander des données qui ne devraient pas être accessibles au public. Ils peuvent également abuser d’une API en l’inondant de requêtes afin de submerger l’application ou le serveur qui héberge l’API ; un exemple d’attaque par déni de service (DoS, Denial-of-Service en anglais).

La sécurité des API permet de se prémunir contre ces risques. En comprenant les menaces qui pèsent sur la sécurité des API et en prenant des mesures pour les atténuer, les développeurs peuvent concevoir, mettre en œuvre et déployer des API qui résistent aux abus et aux attaques.

Sécuriser les API tout au long de leur cycle de vie

Pour protéger les API, les développeurs doivent intégrer la sécurité à toutes les étapes clés du cycle de vie de l’API, notamment :

• Design : Lors de la conception du fonctionnement d’une API, les développeurs doivent tenir compte de considérations telles que l’inclusion de contrôles d’accès appropriés et de capacités de limitation du débit.
• Implémentation : Lors de l’écriture du code de mise en œuvre d’une API, il est important d’éviter les erreurs qui pourraient empêcher certaines des capacités de sécurité prévues de fonctionner correctement.
• Tests : Les développeurs testent généralement les API avant de les déployer pour une utilisation réelle. Les tests doivent permettre de déterminer si les API sont résistantes aux attaques de sécurité et d’évaluer les performances.
• Utilisation : Lorsque les API sont utilisées, c’est-à-dire qu’elles sont disponibles pour les applications de production, les équipes doivent surveiller les signes d’attaque et y répondre, comme un volume important de demandes d’API inhabituelles provenant d’une source non fiable.

Principales menaces pour la sécurité des API

La principale référence en matière de menaces pour la sécurité des API est la liste de l’OWASP intitulée Top 10 API Security Risks (10 principaux risques pour la sécurité des API). Les principales menaces identifiées par l’OWASP sont les suivantes :

• Défaillance de l’autorisation au niveau de l’objet : Ce risque survient lorsqu’une API ne parvient pas à valider les utilisateurs ou les requêtes avant d’accorder l’accès à un objet (c’est-à-dire une ressource, telle qu’un type de données, que l’API peut servir). En exploitant cette faille, les attaquants peuvent accéder à des données ou à d’autres objets qui ne devraient pas leur être accessibles.
• Défaillance de l’authentification : Les API qui n’authentifient pas correctement les requêtes (ou qui ne disposent d’aucun mécanisme d’authentification) sont sujettes à une authentification défaillante. Cela permet aux attaquants d’émettre des requêtes qui ne devraient pas leur être accessibles en agissant comme s’ils étaient des utilisateurs légitimes de l’API.
• Falsification de requête côté serveur : Une SSRF (en anglais, Server-Side Request Forgery) se produit lorsqu’une API répond à une requête sans vérifier si la destination requise est légitime. Les attaquants peuvent abuser de cette faille pour envoyer des requêtes à des destinations de leur choix, ce qui entraîne l’exposition de données sensibles.
• Accès illimité : Les API sans restrictions d’accès peuvent être utilisées de manière abusive pour perturber la disponibilité d’une application ou d’un service. Par exemple, si une application n’impose pas de limite au nombre de requêtes API qu’elle peut traiter par minute, des attaquants pourraient en émettre tellement qu’ils provoqueraient son arrêt.
• Défaillance de l’autorisation au niveau de la fonction : Ce type de vulnérabilité affecte les API qui ne valident pas correctement les demandes de fonctionnalité de l’API. Par exemple, une API peut permettre à un utilisateur non authentifié de demander à une application d’effectuer une action que les développeurs ont prévu de mettre à la disposition des seuls utilisateurs authentifiés.

D’autres types de risques courants liés à la sécurité des API ne figurent pas sur la liste de l’OWASP :

• Injection : Une attaque par injection d’API se produit lorsque les API acceptent des entrées sans les valider correctement, ce qui permet aux attaquants d’insérer des requêtes malveillantes dans une application.
• Données excédentaires : Les API ne doivent exposer que les données minimales nécessaires pour répondre à une requête. Celles qui fournissent davantage de données sont exposées à des risques de données excessives, qui pourraient entraîner la fuite d’informations sensibles.
• Shadow API : Une shadow API, ou API fantôme, est une API qui est exposée mais qui n’est pas correctement sécurisée, gérée ou surveillée. Les API fantômes apparaissent souvent parce que les développeurs d’une partie de l’organisation mettent en œuvre une API sans en informer les autres ou sans respecter les règles de l’entreprise en matière de conception et de sécurité des API. Elles représentent un risque car l’absence de normes de sécurité et de suivi peut les rendre plus facilement attaquables.

Meilleures pratiques en matière de protection des API

Étant donné que le contexte de sécurité et d’utilisation des API peut varier, il n’existe pas d’ensemble unique de mesures que les développeurs peuvent suivre pour maximiser la sécurité des API. En outre, les différents cas d’utilisation des API signifient que les normes de sécurité peuvent varier. Par exemple, lors de la conception d’une API publique, il peut être inutile d’exiger l’authentification, puisque l’objectif de la plupart des API publiques est de permettre à une application de recevoir des données de n’importe quelle autre application ou service. Toutefois, une API privée doit exiger une authentification dans la plupart des cas, car les API privées ne permettent des connexions qu’avec des applications et des services de confiance.

Cela dit, il existe des bonnes pratiques générales de sécurité et des protections d’API qui peuvent contribuer à atténuer les menaces de sécurité contre les API de pratiquement tous les types, dans tous les cas d’utilisation :

• Toujours crypter les données : Les données échangées via les API doivent être cryptées. Le chiffrement réduit le risque que des tiers puissent intercepter et lire des données sensibles au cours d’une transaction API.
• Exiger une authentification forte : Pour les API qui n’ont pas besoin de prendre en charge les requêtes non authentifiées, les développeurs doivent mettre en œuvre une authentification forte via des méthodes telles que OAuth ou JWT.
• Tester les API pour détecter les failles de sécurité : Pour détecter les menaces à la sécurité des API que les développeurs n’ont peut-être pas détectées, il est recommandé d’effectuer des tests qui simulent une activité malveillante contre les API et d’évaluer la façon dont elles réagissent.
• Limiter les requêtes d’API : Pour limiter le risque d’abus d’API, les entreprises peuvent restreindre le nombre de requêtes acceptées par une API. Les restrictions peuvent être mises en œuvre au sein de l’API elle-même ou appliquées à l’aide d’un outil tel qu’une passerelle API (un intermédiaire qui intercepte les demandes d’API entre les applications et peut bloquer les requêtes malveillantes).
• Surveiller les API : La surveillance des API en cours d’exécution (c’est-à-dire pendant la période où les API sont disponibles pour une utilisation réelle) peut révéler des tentatives d’attaques ou d’abus, comme une série de requêtes inhabituelles, qui pourraient refléter les efforts déployés par les acteurs malveillants pour découvrir et exploiter les failles de sécurité dans les mécanismes d’authentification ou d’autorisation d’une API.

Sécurité des API et sécurité des applications générales

La sécurité des API partage certains concepts et pratiques avec la sécurité des applications. Par exemple, il est important dans les deux contextes de mettre en œuvre des contrôles d’authentification solides et d’effectuer des tests de sécurité adéquats avant de mettre les produits en production.

Toutefois, les API ne sont pas identiques aux applications et la sécurité des API diffère de celle des applications sur des points essentiels :

• Types d’attaques : Les applications sont soumises à un éventail plus large de types d’attaques potentielles, allant des risques d’injection de code aux attaques de la chaîne d’approvisionnement, à l’exploitation des vulnérabilités, etc. En revanche, la plupart des attaques contre les API abusent d’une authentification, d’une autorisation ou de contrôles de limitation de débit faibles ou inexistants.
• Failles basées sur el code : Dans le domaine de la sécurité applicative, les failles dans le code source (telles que l’absence de validation des entrées) sont une source courante de risques pour la sécurité. Les API dépendent également du code, mais celui-ci est moins étendu et est rarement à l’origine des problèmes de sécurité. Au contraire, les failles de sécurité des API ont tendance à résulter d’erreurs de conception, comme le fait de ne pas exiger d’authentification.
• Outils de sécurité : Les outils disponibles pour sécuriser les applications sont différents de ceux utilisés pour sécuriser les API. Par exemple, les scanners de vulnérabilité qui recherchent les composants logiciels liés à des CVE sont un outil essentiel pour la sécurité des applications, mais ils ne vous aideront pas à protéger les API. Au lieu de cela, pour analyser une API, vous utiliserez généralement un type de scanner qui simule des requêtes malveillantes (les scanners DAST utilisent une méthode similaire pour vérifier les risques liés à la sécurité applicative, mais ils ne constituent qu’un type de scanner de la sécurité des applications).

JFrog et la sécurité des API

La plateforme de la chaîne d’approvisionnement logicielle JFrog offre une variété de protections, telles que l’analyse des applications, l’analyse des secrets, sécurité de la chaîne d’approvisionnement et la gestion sécurisée des artefacts, afin de sécuriser les applications et de limiter les risques, quelle que soit leur origine.