Aperçu et meilleures pratiques de la sécurité des API OWASP

Des mesures de sécurité API robustes sont nécessaires pour protéger les données contre tout accès, manipulation ou exposition non autorisés afin de garantir la confidentialité et de maintenir la confiance des utilisateurs et des parties prenantes, ainsi que pour garantir la confidentialité, l’intégrité et la disponibilité des API. Les meilleures 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 garantir 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 d’API sensibles, ainsi qu’aux objets et fonctions pertinents.
• Valider l'encodage d'entrée et de sortie. Validez et nettoyez toutes les entrées reçues des clients API pour empêcher les attaques par injection et codez la sortie de manière appropriée pour empêcher l'exécution de scripts malveillants.
• Utilisez une communication sécurisée. Utilisez des protocoles sécurisés pour transmettre des données entre les clients et les serveurs API et cryptez les informations sensibles en transit et au repos pour garantir la confidentialité et l'intégrité des données. 
• Mettre en œuvre la limitation et la limitation du débit. Appliquez des limites au nombre de requêtes que les clients API peuvent effectuer dans un délai spécifié pour empêcher une utilisation excessive ou des tentatives d'accès non autorisées, telles que le 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 de pénétration et des revues de code pour identifier et corriger les vulnérabilités potentielles de vos API, et effectuez des audits de sécurité pour détecter les faiblesses et garantir la conformité aux normes et mandats du secteur. Ceci est particulièrement important en raison des interdépendances des API et des frameworks et bibliothèques sous-jacents.
• Appliquer la conformité du schéma et du protocole. La création et l'application automatiques d'un modèle de sécurité positif avec les spécifications OpenAPI sont un outil précieux pour garantir une politique de sécurité cohérente.
• Découvrez dynamiquement et évaluez en continu les API. La prolifération des API a donné lieu à des API non comptabilisées ou non maintenues, y compris des API fantômes . Les contrôles de sécurité doivent constamment inventorier et protéger les API à l’aide de paradigmes d’accès de confiance zéro 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 à diverses menaces et doivent être protégées contre celles-ci, notamment les exploits, les mauvaises configurations, les robots, la fraude et les abus.

Le Top 10 de la sécurité des API 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, concepteurs, architectes, gestionnaires et autres personnes impliquées dans le développement et la maintenance des API à maintenir une approche proactive de la sécurité des API.

Les 10 principaux risques de sécurité des API OWASP pour 2023 sont :  

1. Autorisation au niveau de l'objet rompue. 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 mise en œuvre incorrecte 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'un objet et exécute une action sur l'objet doit implémenter des contrôles d'autorisation au niveau de l'objet pour valider que l'utilisateur connecté dispose des autorisations nécessaires pour effectuer l'action demandée sur l'objet demandé.
2. Authentification brisée. Les mécanismes d’authentification dans une API sont souvent implémentés 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 faibles, de failles de gestion de session ou d'autres faiblesses dans le flux de travail d'authentification. 
3. Autorisation au niveau de la propriété de l'objet cassé. Cette menace se produit lorsqu'une API ne parvient pas à appliquer correctement les contrôles d'accès et les contrôles d'autorisation au niveau de la propriété de l'objet. Un point de terminaison d'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 de 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 illimitée de ressources. 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 rompue. 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, permettant aux attaquants d'accéder à des fonctionnalités non autorisées. La mise en œuvre de contrôles d’autorisation appropriés peut être déroutante, 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 illimité aux 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 pris en charge par l'API. Ces flux commerciaux peuvent prendre en charge l'achat en masse de produits de grande valeur et à faible stock tels que des billets ou des baskets, qui peuvent être revendus avec une marge sur les marchés secondaires. Les attaquants réorganisent souvent leurs attaques à l’aide de boîtes à outils d’automatisation sophistiquées et peuvent se tourner vers la logique métier ciblée derrière les API si les applications Web de la cible sont correctement protégées par des défenses anti-automatisation.  
7. Falsification de requête côté serveur (SSRF). Cette vulnérabilité survient 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 internes ou des systèmes qu’il souhaite cibler. Ignorant l'intention malveillante, le serveur exécute la requête côté serveur à l'URL spécifiée, exposant potentiellement des informations ou des services sensibles. 
8. Mauvaise configuration de sécurité. Les attaquants tentent de trouver des failles non corrigées, des points de terminaison courants, des services exécutés avec 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 survenir lorsque le renforcement de la sécurité approprié est manquant à n'importe quel niveau de la pile d'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 a un impact sur les applications Web et les API et constitue un risque croissant à mesure que l'architecture continue de se décentraliser et de se distribuer 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 être laissés en cours d'exécution sans correctif ou avec des exigences de sécurité plus faibles, augmentant ainsi le risque de failles de sécurité. L’absence d’une gestion appropriée des stocks rend difficile le suivi des versions utilisées, de celles qui sont obsolètes ou obsolètes et des vulnérabilités qui ont été corrigées. Les API Shadow et Zombie présentent des risques importants , soulignant l’importance de la découverte continue et des protections automatisées.  
10. Consommation dangereuse des API. Les développeurs ont tendance à faire confiance aux données reçues d’API tierces, en particulier d’API proposées par des entreprises renommées, et à adopter des exigences de sécurité plus faibles pour ces données en termes de validation et de nettoyage des entrées ou de sécurité du transport. Une consommation non sécurisée peut également se produire lorsque les API sont accessibles via des protocoles non sécurisés ou lorsque des mécanismes de cryptage appropriés ne sont pas utilisés, ce qui entraîne des écoutes clandestines, des interceptions de données et un accès non autorisé à des informations sensibles.