API Security Top 10 de l’OWASP - Présentation et bonnes pratiques

Des mesures robustes de sécurisation des API sont nécessaires pour protéger les données contre l’accès, la manipulation ou l’exposition non autorisés afin de garantir la confidentialité et de maintenir la confiance des utilisateurs et des parties prenantes, ainsi que de garantir la confidentialité, l’intégrité et la disponibilité des API. Les bonnes pratiques en matière de sécurité des API sont les suivantes :

• Mettre en œuvre une authentification et une autorisation fortes. Appliquez des contrôles d’autorisation appropriés pour s’assurer que les clients authentifiés disposent des autorisations nécessaires pour accéder à des ressources spécifiques ou effectuer certaines actions. Utilisez des contrôles d’accès granulaires pour limiter l’accès aux points de terminaison ou aux données API sensibles, ainsi qu’aux objets et fonctions pertinents.
• Valider le codage en entrée et en sortie. Validez et désinfectez toutes les entrées reçues des clients des API pour empêcher les attaques par injection et encodez les sorties de manière appropriée pour empêcher l’exécution de scripts malveillants.
• Utiliser une communication sécurisée. Utilisez des protocoles sécurisés pour la transmission de données entre les clients et les serveurs des API et chiffrez les informations sensibles en transit et au repos pour assurer la confidentialité et l’intégrité des données.
• Mettre en œuvre la limitation et l’étranglement du débit. Appliquez des limites au nombre de demandes que les clients des API peuvent exécuter dans un délai spécifié pour empêcher une utilisation excessive ou des tentatives d’accès non autorisées, telles que les attaques par déni de service distribué (DDoS) et les attaques par force brute.
• Effectuez régulièrement des tests et des audits de sécurité. Effectuez régulièrement des évaluations de sécurité, des tests d’intrusion et des examens du code pour identifier et traiter les vulnérabilités potentielles de vos API, et effectuez des audits de sécurité pour détecter les faiblesses et assurer la conformité avec les normes et les mandats de l’industrie. Ceci est particulièrement important en raison des interdépendances des API et des cadres et bibliothèques sous-jacents.
• Appliquer la conformité des schémas et des protocoles. La création et l’application automatiques d’un modèle de sécurisation positif utilisant les spécifications OpenAPI s’avèrent un outil précieux pour assurer une politique de sécurité cohérente.
• Découvrir et évaluer les API de manière dynamique et continue. La prolifération des API a entraîné l’apparition d’API non prises en compte ou non entretenues, notamment des API fantômes. Les contrôles de sécurité doivent constamment inventorier et protéger les API en utilisant des paradigmes d’accès sans confiance et de moindre privilège pour atténuer les risques imprévus d’interdépendances avec des tiers.
• Détection complète des menaces. Les API sont soumises à et doivent être protégées contre diverses menaces, notamment les exploits, la mauvaise configuration, les robots, la fraude et les abus.

L’API Security Top 10 de l’OWASP – 2023 a été formulé pour accroître la sensibilisation aux faiblesses courantes de la sécurité des API et pour aider les développeurs, les concepteurs, les architectes, les gestionnaires et les autres personnes impliquées dans le développement et la maintenance des API à maintenir une approche proactive par rapport à la sécurité des API.

Les 10 principaux risques liés à la sécurité des API recensés par l’OWASP pour 2023 sont les suivants :  

1. Autorisation au niveau des objets déficiente. Cette vulnérabilité de sécurité se produit lorsqu’une application ne parvient pas à appliquer correctement les contrôles d’accès au niveau de l’objet ou des données, permettant à un attaquant de manipuler ou de contourner les contrôles d’autorisation et d’accorder un accès non autorisé à des objets ou des données spécifiques au sein d’une application. Cela peut se produire en raison d’une mauvaise mise en œuvre des contrôles d’autorisation, d’un manque de validation appropriée ou d’un contournement des contrôles d’accès. Chaque point de terminaison d’API qui reçoit un ID d’objet et effectue une action sur l’objet doit mettre en œuvre des vérifications d’autorisation au niveau de l’objet pour valider le fait que l’utilisateur connecté dispose des autorisations nécessaires pour effectuer l’action demandée sur l’objet demandé.
2. Authentification déficiente. Dans une API, les mécanismes d’authentification sont souvent mis en œuvre de manière incorrecte, ce qui permet aux attaquants d’obtenir un accès non autorisé aux comptes d’utilisateurs ou aux données sensibles, ou d’effectuer des actions non autorisées. Cela se produit généralement en raison d’une mise en œuvre ou d’une configuration incorrecte des processus d’authentification, de politiques de mot de passe insuffisantes, de failles de gestion des sessions ou d’autres faiblesses dans le flux de travail d’authentification.
3. Autorisation de niveau de propriété d’objet déficiente. Cette menace se produit lorsqu’une API ne parvient pas à appliquer correctement les contrôles d’accès et les vérifications d’autorisation au niveau de la propriété de l’objet. Un point de terminaison API est vulnérable à ces attaques s’il expose les propriétés d’un objet qui sont considérées comme sensibles et ne doivent pas être lues par l’utilisateur, un exploit parfois appelé exposition excessive des données. Un point de terminaison d’API est également vulnérable à ces attaques s’il permet à un utilisateur de modifier, d’ajouter ou de supprimer la valeur de la propriété d’un objet sensible, un exploit parfois appelé affectation de masse.
4. Consommation de ressources illimitée. Cette attaque, également appelée épuisement des ressources, consiste à exploiter les faiblesses de l’implémentation de l’API pour consommer intentionnellement une quantité excessive de ressources, telles que le processeur, la mémoire, la bande passante ou d’autres ressources système. Ce déni de service (DoS) dégrade les performances ou la disponibilité de l’API ou du système sous-jacent et peut entraîner des temps d’arrêt.
5. Autorisation de niveau de fonction déficiente. Cette menace se produit lorsqu’une API ne parvient pas à appliquer correctement les contrôles d’autorisation au niveau de la fonction ou de l’opération, ce qui permet aux attaquants d’accéder à des fonctionnalités non autorisées. La mise en œuvre de contrôles d’autorisation appropriés peut être source de confusion, car les applications modernes peuvent définir de nombreux types de rôles et de groupes fonctionnels et impliquer des hiérarchies d’utilisateurs complexes, que les attaquants peuvent manipuler.
6. Accès sans restriction à des flux commerciaux sensibles. Cette attaque se produit lorsqu’une API ne dispose pas de contrôles d’accès ou de vérifications d’autorisation appropriés, ce qui permet aux attaquants d’automatiser l’accès aux flux commerciaux sensibles reposant sur l’API. Ces flux peuvent soutenir l’achat en masse de produits de grande valeur en faible nombre, tels que des billets ou des baskets, qui peuvent ensuite être revendus avec une marge sur les marchés secondaires. Les attaquants réoutillent souvent leurs attaques à l’aide de boîtes à outils d’automatisation sophistiquées et peuvent pivoter pour cibler la logique commerciale derrière les API si les applications web de la cible sont adéquatement protégées par des défenses anti-automatisation.
7. Falsification de requêtes côté serveur (SSRF). Cette vulnérabilité se produit lorsqu’un attaquant identifie un point de terminaison d’API vulnérable qui accepte les URL fournies par l’utilisateur ou exécute des requêtes côté serveur vers des ressources externes. L’attaquant crée des requêtes malveillantes qui spécifient les URL des ressources ou des systèmes internes qu’il souhaite cibler. Ignorant l’intention malveillante, le serveur exécute la requête côté serveur vers l’URL spécifiée, exposant potentiellement des informations ou des services sensibles.
8. Mauvaise configuration de la sécurité. Les attaquants tentent de trouver des failles non corrigées, des points de terminaison communs, des services exécutés ayant des configurations par défaut non sécurisées ou des fichiers et répertoires non protégés pour obtenir un accès non autorisé à l’API. Cette vulnérabilité peut se produire lorsqu’un renforcement approprié de la sécurité est absent à tous les niveaux de la pile de l’API, du réseau au niveau de l’application, ou s’il existe des autorisations mal configurées sur les services cloud. Une mauvaise configuration va avoir un impact sur les applications web et les API, et constitue un risque croissant à mesure que l’architecture continue sa décentralisation et sa distribution dans des environnements multicloud.
9. Mauvaise gestion des stocks. Les API sont sujettes à des modifications et à des mises à jour au fil du temps, mais des versions d’API obsolètes ou non sécurisées peuvent rester en production, ou des points de terminaison plus anciens peuvent ne pas être corrigés ou utiliser des exigences de sécurité plus faibles, ce qui augmente le risque d’atteinte à la sécurité. Une gestion inappropriée des stocks rend difficile le suivi des versions utilisées, des versions obsolètes ou désapprouvées et des vulnérabilités qui ont été corrigées. Les API fantômes et zombies présentent des risques importants, soulignant l’importance de la découverte continue et des protections automatisées.  
10. Consommation dangereuse d’API. Les développeurs ont tendance à faire confiance aux données reçues des API tierces, en particulier des API proposées par des entreprises réputées, et adoptent des exigences de sécurité plus faibles pour ces données en termes de validation des entrées et d’assainissement ou de sécurisation du transport. Une consommation dangereuse peut également se produire lorsque l’accès aux API se fait via des protocoles non sécurisés ou lorsque les mécanismes de chiffrement appropriés ne sont pas utilisés, ce qui conduit à l’écoute clandestine, à l’interception de données et à l’accès non autorisé à des informations sensibles.