Liste des 10 principaux risques pour la sécurité des API de l'OWASP : l'édition 2023 a enfin été publiée
Les interfaces de programmation d'applications (API) actuelles permettent une intégration flexible, et rapide entre pratiquement tous les logiciels, terminaux et sources de données. Les API offrent un large éventail de fonctionnalités et constituent une base pour l'innovation et la transformation digitale.
Les API sont également devenues la norme de fait pour la création et la connexion des applications actuelles, particulièrement en raison de la migration croissante vers des architectures basées sur les microservices. Vos API servent à relier les différents systèmes digitaux. Il est donc essentiel de les sécuriser de manière adaptée.
Chacun de ces appels d'API peut potentiellement créer des failles de sécurité et engendrer des risques pour la confidentialité (mauvaise validation des données, erreurs de configuration, failles de mise en œuvre ou encore manque d'intégration entre les composants de sécurité). Il est primordial d'en tenir compte lors des réponses aux vulnérabilités évoquées dans la liste des 10 principaux risques pour la sécurité des API dressée par l'Open Web Application Security Project (OWASP).
Le 5 juin 2023, l'OWASP a publié la première mise à jour importante de leur liste initialement rendue publique en 2019. Étudions les modifications apportées et identifions les facteurs clés qui influencent les vulnérabilités actuelles des API pour que vous ayez toutes les clés en main avant de sécuriser vos API.
Liste des 10 principaux risques pour la sécurité des API de l'OWASP
OWASP est une entreprise non gouvernementale qui rédige des documents de sensibilisation à la sécurité basés sur les commentaires de la communauté et sur les évaluations d'experts comme ceux d'Akamai. Ces documents présentent les types de vulnérabilités qui touchent le plus les entreprises d'aujourd'hui. Des développeurs aux RSSI, ces éléments sont des ressources précieuses pour toute personne impliquée dans les API.
L'OWASP a décidé de publier un document distinct sur les 10 principaux risques pour la sécurité des API en plus de ses autres listes des 10 principaux risques, afin de souligner que la sécurité des API, nécessite une approche unique. Le projet de sécurisation des API de l'OWASP « se concentre sur les stratégies et les solutions dans une démarche de compréhension et d'atténuation des vulnérabilités uniques et des risques de sécurité des… API ».
Les différences
Étudions les différences entre les éditions 2019 et 2023 (Figure 1).
Figure 1 : les modifications apportées à la liste 2023 des 10 principaux risques pour la sécurité des API de l'OWASP
Selon les notes de la mise à jour 2023 :
La liste 2023 des 10 principaux risques pour la sécurité des API de l'OWASP vise à anticiper et à sensibiliser une industrie en pleine évolution. Elle ne vise pas à se substituer à d'autres listes. Dans ce numéro :
- Nous avons combiné l'exposition excessive de données et l'affectation en masse pour nous focaliser sur la cause profonde commune : les échecs de validation de l'autorisation au niveau de la propriété de l'objet.
- Nous nous sommes davantage focalisés sur la consommation des ressources avec un angle d'approche spécifique : le rythme auquel elles s'épuisent.
- Nous avons créé une nouvelle catégorie « Accès illimité aux flux d'activité sensibles » pour faire face aux nouvelles menaces, y compris à la plupart de celles qui peuvent être atténuées par limitation de débit.
- Nous avons ajouté la « Consommation d'API non sécurisée » pour résoudre un problème que nous avons commencé à observer : les cybercriminels ont commencé à étudier les services intégrés d'une cible pour les compromettre au lieu de frapper directement les API de leur cible. C'est le bon moment pour commencer à sensibiliser la communauté à ce risque croissant.
Les nouveaux éléments, les éléments figurant déjà sur la liste et les éléments qui en sont retirés
NOUVEAUX ÉLÉMENTS | API3 : 2023 | Autorisation brisée au niveau de la propriété de l'objet
L'OWASP a combiné les anciennes catégories d'exposition excessive de données et d'affectation en masse pour créer sa nouvelle autorisation brisée au niveau de la propriété de l'objet (BOPLA), et pour ce faire, la communauté s'est focalisée sur la cause profonde commune : les échecs de validation de l'autorisation au niveau de la propriété de l'objet.
La différence entre la BOLA (Autorisation brisée au niveau de la propriété de l'objet) et la BOPLA est simple : la BOLA s'applique à un objet entier là où la BOPLA s'applique à une propriété interne de l'objet (Figure 2).
Figure 2 : la BOPLA concerne la propriété interne d'un objet
L'OWASP et Akamai observent encore des risques majeurs au niveau des objets. C'est donc pour cela que la BOLA reste le risque le plus important et le plus conséquent qui pèse sur la sécurité de vos API.
Cependant, en creusant davantage et en étudiant le niveau de propriété de l'objet, vous vous exposez à des risques supplémentaires : le surpartage d'informations et l'autorisation involontaire accordée à des propriétés spécifiques qui peuvent être modifiées ou supprimées.
Une organisation concernée par la BOLA n'est pas forcément concernée par la BOPLA. La combinaison de l'exposition excessive des données et de l'alignement en masse dans une seule et même catégorie souligne l'attention requise par les développeurs d'API au niveau des propriétés d'un objet.
Cette distinction doit impérativement être faite par les personnes qui choisissent un produit de sécurité des API, car elles doivent se protéger de ces deux types d'attaques.
ÉLÉMENT FIGURANT DÉJÀ SUR LA LISTE | API6 : 2023 | Falsification de requête côté serveur
L'OWASP a réduit les risques de sécurité liés à l'injection. Cette dernière a donc été retirée du Top 10 pour laisser sa place à la Falsification de requête côté serveur (SSRF) .
La SSRF est un type d'attaque qui exploite la vulnérabilité d'une application Web ou d'une API. Elle permet à un cybercriminel d'envoyer des requêtes non autorisées à des systèmes internes ou externes, et ce depuis le serveur.
Voici quelques raisons qui auraient pu encourager l'OWASP à opter pour un tel changement :
- Les API reposent sur des technologies de pointe comme Kubernetes et Docker qui exploitent des protocoles de communication basés sur l'API HTTPS. Elles sont donc plus vulnérables aux attaques par SSRF.
- Grâce aux technologies comme les webhooks, les intégrations d'authentification unique et la récupération/redirection de fichiers URL par les terminaux des API, les personnes malintentionnées ont de nombreuses passerelles pour leur SSRF.
Présentation détaillée
Pour en savoir plus sur les attaques par SSRF, lisez l'article de Mike Elissen Vos API attirent les attaques par falsification de requête côté serveur (SSRF).
ÉLÉMENT RETIRÉ DE LA LISTE | API8 : 2019 | Injection
Au sein de la communauté de sécurité des API, la suppression des attaques par injection de la liste a été perçue comme audacieuse et a même fait l'objet de controverses. Mais il s'avère que la menace des attaques par injection sur les terminaux des API est minime.
L'injection relève désormais des prérogatives de l'API suivant : API8 : 2023 | Configuration inadéquate de la sécurité. Une configuration de sécurité appropriée doit inclure des mécanismes de protection des applications Web et des API destinés à analyser et à empêcher les injections par défaut.
GraphQL devient progressivement une technologie d'API. À l'origine, il s'agit d'un langage de requête qui pourrait rouvrir la porte à une augmentation des attaques par injection. Les développeurs d'API qui misent sur GraphQL doivent donc redoubler de vigilance.
NOUVEAUX ÉLÉMENTS | API4 : 2023 | Consommation illimitée des ressources
La liste de base se concentrait tout particulièrement sur la maîtrise du risque de consommation des ressources conduisant à l'inondation des terminaux d'API (et potentiellement à leur indisponibilité), ce qui nuit à l'expérience utilisateur.
Aujourd'hui, les terminaux des API doivent être disponibles, mais la disponibilité ne fait pas tout. La mise en œuvre de contrôles des passerelles d'API, de l'équilibrage de la charge ou de la limitation de débit est une première étape encourageante.
Ces dernières années, nous assistons à un tournant majeur de l'« économie d'utilisation des API ». Cette catégorie actualisée vise à sensibiliser le public à cet aspect, lequel continuera à se développer grâce à l'intégration d'API tierces.
NOUVEAUX ÉLÉMENTS | API6 : 2023 | Accès illimité aux flux d'activité sensibles
L'ajout suivant a aussi été recensé : API6 : 2023 Accès illimité aux flux d'activité sensibles. Cette catégorie a fini par codifier ce qui rend la sécurité si spéciale : penser davantage comme un cybercriminel et identifier les gains potentiels.
La technologie (l'API) n'est qu'un moyen d'exécuter la logique métier. Utiliser de méthodes pour contourner ou modifier cette logique métier par le biais de la technologie est donc peu souhaitable puisque cela pourrait entraîner des complications.
L'OWASP a partagé des exemples spécifiques pour illustrer la façon dont ces complications peuvent être évitées, mais ce risque pour la sécurité est intrinsèquement lié à la logique métier prise en charge par les terminaux de vos API.
Développeurs d'API : exemple
Récemment, Mike Elissen a échangé avec les développeurs d'API d'un service de streaming. Pour attirer plus d'audience, ce service de streaming offrait un essai gratuit de 30 jours aux nouveaux utilisateurs qui partageaient leurs informations de carte bancaire.
Cependant, la logique métier veut que nous recherchions des adresses e-mail uniques pour les nouvelles inscriptions. Une nouvelle adresse e-mail pouvait facilement accéder à un nouvel essai en utilisant les mêmes informations de carte bancaire. Les utilisateurs pourraient donc créer de nouveaux comptes chaque mois pour utiliser le service gratuitement.
NOUVEAUX ÉLÉMENTS | API10 : 2023 | Consommation d'API non sécurisée
Alors que la consommation d'API tierces connaît une croissance rapide, les API doivent intégrer différents services internes et externes (tiers) et communiquer avec eux en envoyant et en recevant des données.
Les règles de sécurité « de base » doivent impérativement être suivies, même dans ces cas. Il peut être compliqué pour les produits de sécurité de détecter les vulnérabilités et de vous défendre proactivement dans cet espace.
Le document de l'OWASP inclut diverses suggestions générales ou spécifiques à une API. En voici quelques exemples :
- Faites preuve de vigilance lors des redirections. Intégrez cette surveillance à la logique métier et déployez des solutions de sécurité qui surveillent et inspectent en permanence les flux de trafic.
- Ne faites pas confiance aux API tierces, même si elles ont une bonne réputation. Mettez en place des défenses et des limites applicables à vos applications et aux terminaux de vos API.
Akamai peut contribuer à la sécurité des API
Les entreprises et leurs fournisseurs de solutions de sécurité doivent travailler en étroite collaboration, en alignant l'ensemble des utilisateurs, des processus et des technologies afin d'établir une défense solide contre les risques de sécurité décrits dans la liste des 10 principaux risques pour la sécurité des API de l'OWASP.
Akamai met à votre disposition des solutions de sécurité de pointe, des experts hautement qualifiés et son cloud Akamai Connected Cloudqui rassemble des informations sur des millions d'attaques d'applications Web, des milliards de demandes de bots et des milliers de milliards de demandes API. Les solutions de sécurité des applications Web et des API d'Akamai vous aideront à protéger votre entreprise contre les formes les plus avancées d'attaques d'applications Web, d'attaques par déni de service distribué et d'attaques basées sur les API.
Akamai + Neosec
La nouvelle version d'OWASP coïncide avec notre récente acquisition de Neosec. La solution de sécurité des API de Neosec viendra compléter le portefeuille de solutions de sécurité d'API et d'applications de premier rang d'Akamai. Elle permettra à Akamai de disposer de davantage de visibilité sur l'écosystème des menaces en pleine croissance qui pèse sur les API.
Cette combinaison a été conçue pour simplifier le processus de sécurisation des API des clients. Elle les aide à identifier toutes leurs API, à évaluer les risques, mais aussi à réagir aux vulnérabilités et aux attaques.
En savoir plus
Découvrez-en davantage sur les solutions de sécurité des API d'Akamai et sur notre acquisition de Neosec.
Félicitations à l'OWASP et encore merci !
Sensibiliser à la sécurité implique un effort énorme de la part de la communauté, et nous remercions l'OWASP d'avoir dirigé ce projet. Un grand merci à Erez Yallon, Inon Shkedy et Paulo Silva pour leur travail d'exception sur l'édition 2023.
Nous tenons également à remercier tous nos contributeurs, en particulier nos amis de chez Akamai : Maxim Zavodchik et Mike Elissen pour leur participation à ce projet et pour avoir sensibilisé la communauté de développeurs sur la sécurité des API.
Informations complémentaires sur les API
Dans le cadre de ses rapports État des lieux d'Internet (SOTI), Akamai suit l'utilisation des API et le volume de trafic API. Lisez les rapports SOTI précédents pour plus d'informations et consultez les rapports SOTI trimestriels.
Ressources supplémentaires
Série de vidéos : Principes fondamentaux de la sécurité des API
Article de blog : Ce que les nouveaux changements apportés à la liste des 10 principaux risques pour la sécurité des API de l'OWASP impliquent pour vous
