Les meilleures pratiques pour sécuriser vos API
Cet article se penche sur divers risques associés aux vulnérabilités des API tout en apprenant les meilleures pratiques courantes de sécurité des API pour mettre en œuvre des mécanismes de sécurité robustes.
Temps de lecture : 8 minutes

L'interface intermédiaire est couramment utilisée pour rationaliser le développement en permettant aux équipes logicielles de réutiliser le code. Les API font également abstraction des fonctionnalités entre les systèmes en dissociant les applications de l'infrastructure sur laquelle elles s'exécutent. Bien que les avantages et les cas d'utilisation des API dans les entreprises modernes continuent d'augmenter, les défis de sécurité inhérents présentent divers risques de sécurité. C'est pourquoi l' OWASP a créé une liste des dix meilleurs pour la sécurité des API.
- Qu'est-ce que la sécurité des API ?
- Risques de vulnérabilités d'API
- Sécurité des API - Meilleures pratiques à prendre en compte
Qu'est-ce que la sécurité des API ?
Une API représente un ensemble de services qui permettent à un programme de communiquer avec un autre programme externe ou interne. Lorsque nous parlons de sécurité des API, nous nous référons généralement à la sécurisation des services backend d'une application, y compris sa base de données, son système de gestion des utilisateurs ou d'autres composants interagissant avec le magasin de données.
La sécurité des API englobe l'adoption de plusieurs outils et pratiques pour protéger l'intégrité d'une pile technologique. Une API solidement sécurisée couvre à la fois les API d'une organisation et ses services. Cela inclut d'empêcher les acteurs malveillants d'accéder à des informations sensibles ou d'entreprendre des actions en votre nom que vous n'aviez pas l'intention qu'ils effectuent. Malheureusement, alors que les API sont un élément crucial des applications modernes, elles sont une cible courante des attaquants pour accéder à des informations sensibles.
Il est essentiel de comprendre comment les applications tierces acheminent les données via l'interface lors de l'utilisation des API. De plus, les API devenant de plus en plus un vecteur d'attaque, les mesures de sécurité des API aident les équipes de sécurité à évaluer les risques de sécurité et à disposer d'un plan complet pour les protéger.
Risques de vulnérabilités d'API
Comme les API sont accessibles au public, elles sont des cibles courantes pour voler des informations sensibles, y compris la logique de l'application, les informations d'identification de l'utilisateur, les numéros de carte de crédit, etc. En outre, les vulnérabilités d'un point de terminaison d'API sont également exploitées par des acteurs malveillants pour obtenir un accès non autorisé à un système ou réseau pour d'autres formes d'attaques telles que les scripts intersites et les injections de code. Le projet de sécurité des applications Web en ligne (OWASP) émet des recommandations basées sur les risques sur les 10 principales vulnérabilités pour sécuriser l'API Web. Ceux-ci inclus:
Authentification utilisateur interrompue
L'authentification de base présente un défi unique dans les API, car l'authentification multifacteur et les connexions basées sur les informations d'identification sont souvent considérées comme peu pratiques pour les appels API. Comme les API s'appuient sur des jetons de session intégrés dans les appels pour authentifier les clients, les API avec une authentification insuffisante, telles que la mise en œuvre défectueuse des jetons d'accès, permettent aux pirates d'usurper l'identité des utilisateurs légitimes. D'autre part, les jetons à longue durée de vie permettront également à l'attaquant de persister, compromettant le système indéfiniment.
Autorisation au niveau de l'objet interrompue
Dans les API, l'autorisation au niveau de l'objet est un mécanisme de contrôle au niveau du code utilisé pour valider l'accès à l'objet. Pour les API présentant des vulnérabilités d'autorisation au niveau de l'objet interrompues, un utilisateur externe peut remplacer l'ID de sa ressource par l'ID de la ressource d'un autre utilisateur. Cela permet aux attaquants d'accéder à la ressource de l'utilisateur spécifié, ce qui entraîne un accès non autorisé aux données sensibles.
Manque de ressources et limitation du débit
Lorsque l'API ne limite pas le nombre et la fréquence des demandes d'un client particulier, il peut effectuer de nombreux appels par seconde. Le client API peut également demander l'accès à plusieurs ressources et enregistrements à la fois, surchargeant le serveur d'applications pour répondre instantanément à plusieurs demandes. Cela peut conduire à des attaques par déni de service car un client effectuant trop de demandes à la fois entrave la capacité du serveur à traiter les demandes. L'absence de limitation de débit encourage également les pirates à effectuer des attaques par force brute sur les terminaux d'authentification.
Affectation en masse
La vulnérabilité d'affectation en masse se produit dans les API qui dirigent automatiquement l'entrée de l'utilisateur vers des objets ou des variables de programme. Bien que cette fonctionnalité simplifie le développement du code, certains utilisateurs peuvent initialiser et écraser des variables côté serveur, compromettant l'application. Les attaquants exploitent principalement cela en devinant et en fournissant des propriétés d'objet supplémentaires lors de la création de requêtes. Ils peuvent également lire la documentation de l'application ou identifier les points de terminaison faibles de l'API qui leur permettent de modifier les objets côté serveur.
Mauvaises configurations de sécurité
Plusieurs mauvaises configurations de sécurité constituent une menace pour les API. Ceux-ci inclus:
Messages d'erreur détaillés
Certaines API envoient des messages d'erreur descriptifs contenant des traces de pile et des informations système, informant l'utilisateur du fonctionnement de l'application sous le capot. Les en-têtes HTTP mal configurés exposent des failles de sécurité que les pirates peuvent utiliser pour exfiltrer des données et effectuer des attaques sophistiquées plus profondes.
Méthodes et services HTTP inutiles
Si les administrateurs ne parviennent pas à fermer les services inutiles, les attaquants malveillants peuvent modifier les ressources publiées à l'aide de différentes méthodes HTTP.
Configurations par défaut non sécurisées
Les API se connectent à des dépendances tierces, dont beaucoup ne sont pas sécurisées par défaut et nécessitent une posture de sécurité améliorée pour faire face à une surface d'attaque élargie.
Sécurité des API - Meilleures pratiques à prendre en compte
Les meilleures pratiques de sécurité des API Web suivantes peuvent aider à atténuer les attaques d'API :
Utiliser la limitation et la limitation du débit
La limitation implique la définition d'un état temporaire qui permet à l'API d'évaluer chaque demande et est souvent utilisée comme mesure anti-spam ou pour empêcher les abus ou les attaques par déni de service. Il y a deux considérations principales lors de la mise en œuvre de la fonctionnalité de limitation : quelle quantité de données doit être autorisée par utilisateur et quand la limite doit-elle être appliquée ?
D'autre part, la limitation du débit aide à administrer la sécurité de l'API REST en évitant les attaques DoS et Brute Force. Dans certaines API, les développeurs définissent des limites souples, qui permettent aux clients de dépasser les limites de requêtes pendant une brève durée. La définition de délais d'expiration est l'une des meilleures pratiques de sécurité des API les plus simples, car elle peut gérer à la fois les requêtes synchrones et asynchrones. Les bibliothèques de files d'attente de requêtes permettent de créer des API qui acceptent un nombre maximum de requêtes, puis placent le reste dans une file d'attente. Chaque langage de programmation est livré avec un répertoire de bibliothèque de files d'attente pour implémenter des files d'attente de requêtes.
Rechercher les vulnérabilités de l'API
Pour maintenir la sécurité continue des services API, il est essentiel d'activer l'analyse automatique, d'identifier les vulnérabilités et de les atténuer à toutes les étapes du cycle de vie du logiciel. Les outils d'analyse automatisés détectent de manière autonome les failles de sécurité en comparant la configuration de l'application à une base de données de vulnérabilités connues. GIFTED vous propose un service de scanner de vulnérabilité qui aide à établir un processus de test continu et élimine le risque de sécurité d'être piraté par les vulnérabilités d'une API. En outre, GIFTED exécute des tests de performance par rapport au top 10 de l'OWASP, fournissant une évaluation rapide de la sécurité pour un large éventail d'applications, d'API et de JavaScripts.
Utiliser HTTPS/TLS pour les API REST
HTTPS et Transport Layer Security (TLS) offrent un protocole sécurisé pour transférer des données cryptées entre les navigateurs Web et les serveurs. Outre d'autres formes d'informations, HTTPS aide également à protéger les identifiants d'authentification en transit. En tant que l'une des pratiques les plus critiques, chaque API doit implémenter HTTPS pour l'intégrité, la confidentialité et l'authenticité. En outre, les équipes de sécurité doivent envisager d'utiliser des certificats côté client mutuellement authentifiés qui offrent une protection supplémentaire pour les données et services sensibles. Lors de la création d'une API REST sécurisée, les développeurs doivent éviter de rediriger HTTP vers HTTPS, ce qui peut rompre la sécurité du client API. Des mesures adéquates doivent également être prises pour détourner le partage des ressources d'origine croisée (CORS) et JSONP requêtes pour leurs vulnérabilités fondamentales pour les appels inter-domaines.
Restreindre les méthodes HTTP
Les API REST activent les applications Web qui exécutent diverses opérations de verbe HTTP possibles. Les données sur HTTP ne sont pas chiffrées et certaines méthodes HTTP peuvent être interceptées et exploitées par des vecteurs d'attaque. En tant que meilleure pratique recommandée, les méthodes HTTP (GET, PUT, DELETE, POST, etc.) qui sont intrinsèquement non sécurisées doivent être interdites. Si une interdiction complète de leur utilisation n'est pas possible, les équipes de sécurité peuvent également appliquer des politiques pour contrôler l'utilisation de ces méthodes avec une liste d'autorisation stricte, dans laquelle toutes les demandes qui ne correspondent pas à la liste doivent être rejetées. Il est également recommandé d'utiliser les meilleures pratiques d'authentification de l'API RESTful pour s'assurer que le client demandeur peut utiliser la méthode HTTP spécifiée sur l'action, l'enregistrement et la collection de ressources.
Mettre en œuvre une validation d'entrée suffisante
En principe, il ne faut pas faire confiance aveuglément aux données fournies par le client API, car le serveur d'authentification peut exécuter un script malveillant provenant d'utilisateurs ou de services applicatifs non autorisés. Pour éviter cela, les équipes de sécurité doivent implémenter des mécanismes de validation des entrées côté client et côté serveur pour éviter les entrées non saines. Alors que la validation côté client implique une indication interactive des erreurs et des conseils à un utilisateur sur les entrées acceptables, une validation côté serveur vérifie en outre les données reçues pour éviter les différents types d' attaques XSS et SQL Injection .
Utiliser une passerelle API
Une passerelle API dissocie l'interface client de la collection d'API backend, fournissant une ressource centralisée pour une disponibilité et une évolutivité cohérentes des services API. Outre la gestion de divers services d'API, la plate-forme de gestion d'API gère également des fonctions standard, notamment la télémétrie, la limitation de débit et l'authentification des utilisateurs, pour maintenir la sécurité entre les services internes. La passerelle agit comme un contrôleur d'accès proxy inverse qui accepte tous les appels d'API, coordonne les ressources nécessaires pour les entretenir et renvoie les résultats appropriés après l'authentification.