Liste de contrôle des tests de sécurité de l'API : 7 étapes clés

Liste de contrôle des tests de sécurité des API

Les meilleures pratiques suivantes peuvent contribuer à garantir qu'un programme de test de sécurité des API est suffisamment approfondi pour assurer une protection efficace contre les risques liés à la sécurité des API.

1. Déterminer qui a la responsabilité globale de tester et de maintenir la sécurité des API

De nombreuses équipes sont impliquées dans le cycle de vie des API, et le projet subira de nombreux changements rapides et itérations au fur et à mesure de son avancement. Il est important de désigner une personne chargée de documenter toutes les API, de veiller à ce que tous les tests soient effectués et que les résultats soient pris en compte.

Avec l'importance croissante des services Cloud et des environnements d'applications web, davantage de divisions métiers et d'autres propriétaires d'applications peuvent être impliqués dans la gouvernance de la sécurité des API que par le passé. Il est donc d'autant plus important de disposer d'un point de contact central.

2. Prévoir du temps et des ressources pour les tests de sécurité

Les tests de sécurité prennent du temps et de l'argent. Les entreprises doivent donc tenir compte de ces facteurs lorsqu'elles lancent un nouveau projet. La modélisation des menaces met en évidence les risques potentiels liés aux API et les vulnérabilités courantes qui doivent être atténuées, mais il faut également prévoir un budget pour la maintenance et la mise à jour des tests d'API une fois le projet mis en œuvre.

Il faut savoir que les API développées et maintenues par des fournisseurs tiers peuvent changer à tout moment. Les équipes chargées de la sécurité et des applications doivent veiller à ce que les tests d'API dynamiques soient pris en compte dans les cycles de planification et de projet.

3. Enregistrer, classer et documenter l'objectif de chaque API et son mode de fonctionnement.

Documenter les API et leur utilisation. Ces informations aident les tests à évaluer si une API peut gérer des actions acceptables et des données valides, ainsi que des actions inacceptables ou des données non valides. Des normes telles que la spécification OpenAPI, AsyncAPI et GraphQL Introspection permettent aux humains et aux machines de découvrir et de comprendre les réponses et les capacités des API. De nombreux outils d'API utilisent ces spécifications pour accélérer le cycle de développement des API.

4. Exécuter les tests à un stade précoce et les automatiser dans la mesure du possible

Tout le monde gagne du temps et de l'argent si les problèmes de sécurité sont détectés dès le début du cycle de développement. Il existe de nombreux outils de sécurité des API, à la fois open source et sous licence, qui peuvent être intégrés dans les workflows existants et les pipelines d'intégration continue/de livraison continue. Les outils dotés de services de simulation (mocking) éliminent la nécessité de construire des répliques à grande échelle des systèmes de production.

Déterminez également qui va effectuer les tests - les développeurs, l'équipe de sécurité ou des testeurs externes si vous ne disposez pas des compétences nécessaires en interne - et à quel moment les tests doivent être effectués. L'idéal est d'exécuter les tests à chaque version de l'application. De nombreux outils de test d'API peuvent désormais être entièrement intégrés pour des tests continus ou déclenchés à la demande.

5. Définir les types de tests à effectuer

Soumettre les évaluations de la sécurité des API aux tests suivants :

• Entrées non valides. Les entrées provenant d'une API doivent être traitées comme si elles provenaient d'une source non fiable et être nettoyées et validées en conséquence. Le fuzzing peut être utilisé pour envoyer des données aléatoires à une API afin de voir si elle peut traiter des données inattendues sans tomber en panne.
• Attaques par injection. Utilisez ces attaques de test pour vous assurer que l'API rejette les demandes qui tentent de manipuler les bases de données dorsales ou d'exécuter les commandes du système d'exploitation sur le serveur sans exposer d'informations sensibles.
• Falsification des paramètres. Les paramètres envoyés par le biais d'une demande d'API, tels que le prix d'un article dans un panier d'achat, sont faciles à modifier pour un pirate. L'altération des paramètres permet de vérifier que l'API valide et contrôle les paramètres avant de les traiter.
• Méthodes HTTP non gérées. Envoyez des requêtes en utilisant les huit méthodes HTTP pour vous assurer que les méthodes inutiles, telles que CONNECT, DELETE, PUT et TRACE, ne sont pas autorisées sur le serveur. Ces méthodes présentent un risque pour la sécurité si elles renvoient une réponse valide plutôt qu'une erreur. Si une application requiert l'une de ces méthodes, assurez-vous que son utilisation est correctement limitée aux utilisateurs de confiance.
• Vulnérabilités de la logique métier. Des failles dans la conception et la mise en œuvre d'une API peuvent permettre à un pirate d'induire un comportement involontaire en interagissant avec l'API d'une manière que les développeurs n'avaient pas prévue - par exemple, en effectuant une transaction sans passer par le processus d'achat prévu. Il est souvent difficile de tester ce type de vulnérabilité à l'aide d'outils automatisés, car la vulnérabilité est généralement propre à l'application et à ses fonctionnalités spécifiques. Une conception claire et des documents de flux de données détaillant les transactions et les worflows, y compris les hypothèses faites à chaque étape, aident à prévenir l'introduction de ce type de vulnérabilité.
• Contrôles d'authentification, d'accès et de chiffrement. S'assurer que l'auteur d'une demande est authentifié auprès du serveur et autorisé à accéder aux ressources demandées. La mise en œuvre de protocoles d'identité et d'autorisation, tels que OpenID Connect et OAuth 2.0, peut s'avérer difficile, tout comme la gestion des clés et des jetons correspondants. Il est important d'allouer du temps supplémentaire pour tester ces contrôles de sécurité.
• Charges excessives. Les contrôles de limite de débit - le nombre de fois qu'une API peut être appelée au cours d'une période - permettent d'arrêter les connexions non autorisées et de se protéger contre les attaques DDoS. Veillez à ce que ces limites soient définies pour obtenir des performances optimales.

Enfin, les messages d'erreur, les entrées de journalisation et la gestion du basculement sont des aspects importants des tests. Il convient donc d'examiner les messages et les journaux pour vérifier que les informations correctes sont enregistrées après chaque test.

6. Corriger les tests qui échouent et refaire les tests

Envoyez les rapports de test à une personne désignée afin de vous assurer que les avertissements et les erreurs sont corrigés. Ensuite, refaites un test pour vous assurer que le code mis à jour a résolu le problème. Les équipes de gestion des vulnérabilités doivent également prévoir les exceptions qui nécessitent l'approbation des parties prenantes responsables. Pour les API tierces qui ne répondent pas aux exigences de sécurité, élaborez un plan de coordination avec le fournisseur de services et refaites des tests si nécessaire.

7. Se tenir au courant des risques de sécurité et mettre à jour la documentation

Toutes les personnes impliquées dans la création d'API doivent comprendre les dernières techniques utilisées par les cybercriminels pour attaquer les API afin de pouvoir mettre à jour le code, les contrôles de sécurité et les tests. L'équipe de sécurité doit régulièrement informer toutes les personnes impliquées dans le projet des nouvelles menaces et des meilleures pratiques.

La liste OWASP API Security Top 10, qui inclut la protection contre les vulnérabilités suivantes, constitue un bon point de départ :

1. L'autorisation au niveau de l'objet n'a pas été respectée.
2. Authentification interrompue.
3. Autorisation au niveau de la propriété de l'objet cassée.
4. Consommation illimitée de ressources.
5. Autorisation de niveau de fonction rompue.
6. Accès illimité aux flux métiers sensibles.
7. Falsification des requêtes côté serveur.
8. Mauvaise configuration de la sécurité.
9. Une mauvaise gestion des stocks.
10. Consommation non sécurisée d'API.

Les API font partie des composants les plus exposés d'un réseau et ont récemment fait l'objet d'attaques, entraînant de nombreuses brèches de données. En raison des risques de sécurité croissants qu'elles présentent, les tests d'API doivent être au cœur de tout projet.