Qu’est-ce que l’analyse des API ?
L’analyse des API détecte automatiquement les vulnérabilités, les erreurs de configuration et les failles logiques de vos API. Concrètement, elle envoie des requêtes simulées à vos endpoints d’API, puis examine les réponses à la recherche de faiblesses.
Pratiques avancées recommandées pour la sécurité dans le cloud
La sécurité des API repose sur des pratiques cloud solides, à approfondir avec la fiche de bonnes pratiques de sécurité cloud de Wiz.
Les organisations exposent toujours plus de services sur Internet et sur leurs réseaux internes. Les API sont ainsi devenues un vecteur d’attaque majeur : 99 % des organisations ont rencontré des problèmes de sécurité liés aux API au cours des 12 derniers mois. La sécurité des applications traditionnelle visait les interfaces web et les navigateurs. Elle passe souvent à côté des pipelines de données backend exposés par les API.
Les outils modernes examinent les spécifications d’API, les endpoints, les méthodes d’authentification et les pratiques de traitement des données. Ils s’alignent généralement sur l’OWASP API Security Top 10. Ce référentiel fait autorité pour comprendre les risques critiques des API.
Les scanners fonctionnent généralement selon deux modes distincts :
Analyse authentifiée : le scanner utilise des identifiants valides pour tester les endpoints protégés. Il couvre ainsi en profondeur la logique interne et l’accès aux données.
Analyse non authentifiée : le scanner se comporte comme un attaquant externe, sans identifiants. Il repère les faiblesses exposées publiquement.
Comment fonctionne l’analyse des API
Tout commence par la découverte : les scanners identifient chaque endpoint d’API de votre environnement. Cette étape est automatique quand l’outil analyse le trafic réseau. Elle se fait aussi manuellement, par l’import de fichiers de spécification.
Les scanners lisent ensuite la documentation de l’API, comme les fichiers OpenAPI/Swagger ou les collections Postman. Cette documentation décrit le comportement attendu de l’API. Elle indique au scanner quels paramètres tester et quelles réponses attendre.
Deux grandes approches d’analyse coexistent :
L’analyse dynamique teste l’API en real-time pendant son exécution (on parle souvent de DAST d’API). Le DAST web interagit avec les interfaces rendues par le navigateur. Le DAST d’API, lui, envoie des requêtes programmatiques directement aux endpoints. Il teste aussi les flux d’authentification (OAuth, JWT), valide la logique d’autorisation et examine les réponses structurées (JSON, XML). Lorsque des fichiers OpenAPI sont disponibles, il s’appuie sur la spécification et cible précisément les paramètres documentés et les comportements attendus.
L’analyse statique examine le code source et les fichiers de configuration sans exécuter l’API. Elle complète l’analyse dynamique du code. Elle révèle en effet des failles dans des chemins de code que les tests runtime n’atteignent pas toujours.
Les scanners contrôlent aussi les réponses de l’API. Ils y traquent les anomalies, comme des données sensibles exposées dans des messages d’erreur.
Ces outils de test de sécurité des API s’intègrent directement dans vos CI/CD pipelines. Une analyse se lance alors à chaque déploiement de code. Vous établissez ainsi une posture de sécurité de référence et détectez immédiatement tout écart.
Une analyse efficace recueille également du contexte sur l’environnement de l’API et la sensibilité des données. Vous savez alors si une vulnérabilité touche des données critiques ou un simple environnement de test.
Types de vulnérabilités détectées par l’analyse des API
L’analyse des API cible des failles précises qui menacent l’intégrité des données et la disponibilité des systèmes. Deux risques comptent parmi les plus lourds de conséquences : Broken Object Level Authorization (BOLA) et Broken Function Level Authorization (BFLA). Tous deux figurent systématiquement dans l’OWASP API Security Top 10.
La BOLA est également appelée IDOR (Insecure Direct Object Reference). Elle survient quand une API ne vérifie pas le droit d’un utilisateur à accéder à un objet précis. Un attaquant remplace par exemple /api/users/123/orders par /api/users/456/orders dans l’URL afin de consulter l’historique de commandes d’un autre client.
Les scanners repèrent la BOLA en testant l’énumération des identifiants d’objets. Ils tentent aussi des accès entre comptes avec différentes sessions authentifiées.
La BFLA apparaît quand une API contrôle mal les permissions au niveau des fonctions. Un utilisateur standard parvient alors à invoquer des opérations réservées aux administrateurs. Un attaquant appelle par exemple DELETE /api/users/789 ou POST /api/admin/reports alors que son rôle ne l’y autorise pas.
La détection exige des comptes de test basés sur les rôles. Elle passe aussi par le test systématique des endpoints privilégiés avec des identifiants aux droits plus faibles.
Autre problème critique : l’exposition excessive de données. Elle se produit quand une API renvoie plus de données que nécessaire et compte sur l’application cliente pour les filtrer. Il suffit alors aux attaquants d’intercepter ce trafic pour consulter des informations sensibles.
Les scanners détectent également les vulnérabilités d’injection, comme l’injection SQL ou l’injection de commandes. Dans ces scénarios, des données non fiables parviennent à un interpréteur au sein d’une commande ou d’une requête.
Parmi les vulnérabilités courantes des API :
Assignation de masse (mass assignment) : l’API accepte des paramètres que le client ne devrait pas modifier, comme « isAdmin=true ».
Erreurs de configuration de sécurité : il s’agit notamment d’en-têtes de sécurité absents, de paramètres CORS mal définis ou d’un chiffrement faible.
Problèmes de limitation du débit : sans limites, les attaquants saturent le système et épuisent ses ressources. Les API attirent aussi une activité de bots disproportionnée : 44 % du trafic de bots avancés les cible malgré leur surface réduite.
Falsification de requête côté serveur (SSRF) : l’attaquant force l’API à envoyer des requêtes vers des ressources internes normalement inaccessibles.
Les failles de logique métier sont propres à chaque application, ce qui les rend plus difficiles à détecter. Elles permettent de détourner des processus légitimes, par exemple acheter un article à 0 €.
| Type de vulnérabilité | Description du risque | Méthode de détection |
|---|---|---|
| Authentification défaillante (Broken Authentication) | Permet la prise de contrôle de comptes | Détournement des jetons et des identifiants de session |
| Injection | Exécute des commandes malveillantes | Fuzzing des paramètres et des entrées |
| Exposition excessive de données | Divulgue des informations privées | Analyse du contenu des réponses |
| Assignation de masse | Modifie des champs protégés | Envoi de paramètres supplémentaires |
Les tests de sécurité des API et le penetration testing des API sont indispensables. Ils révèlent ces risques avant qu’ils ne dégénèrent en incidents.
L’analyse des API dans les environnements cloud-native
Les architectures cloud-native rendent les tests de sécurité des API plus complexes. Les microservices découpent les applications en petits composants indépendants. Ils créent ainsi un vaste réseau d’API internes à sécuriser.
Les ressources cloud sont aussi souvent éphémères : elles apparaissent et disparaissent de façon dynamique. Une analyse ponctuelle devient vite obsolète, d’où l’importance d’une analyse continue.
Plusieurs défis compliquent l’analyse dans les environnements modernes :
API serverless : les fonctions en tant que service (FaaS) réagissent à des événements et n’exposent pas toujours d’endpoints permanents. Elles ne s’exécutent qu’en réponse à des déclencheurs précis : la découverte et les tests dépendent donc du bon timing.
API fantômes (shadow API): ces API non documentées sont déployées hors des processus standard. Elles créent des surfaces d’attaque cachées.
Service meshes : les environnements Kubernetes s’appuient sur des service meshes pour gérer le trafic. Sans intégration avec ces maillages, les scanners perdent en visibilité sur les API.
Les API cloud-native reposent souvent sur des mécanismes d’authentification complexes dans des environnements multi-cloud. Les passerelles d’API (API gateways) y jouent un double rôle : elles centralisent l’application des politiques. Mal testées, elles masquent en revanche des vulnérabilités backend.
Défis de mise en œuvre et bonnes pratiques
La gestion des false positives compte parmi les principaux obstacles de l’analyse des API. Les scanners signalent parfois des comportements inoffensifs comme des risques. Résultat : votre équipe de sécurité souffre d’alert fatigue.
Le Guide Pratique Pour Des Responsables De La Sécurité
La priorisation et la correction des vulnérabilités d’API nécessitent des processus clairs, à structurer avec le guide pratique de Wiz pour les responsables de la sécurité.
La complexité de l’authentification et de l’autorisation constitue un autre défi majeur. Les scanners doivent gérer des schémas variés : flux OAuth 2.0/OIDC, validation JWT, TLS mutuel (mTLS) et requêtes signées.
Les jetons à courte durée de vie et les flux de renouvellement complexes compliquent encore la tâche. Une gestion avancée des identifiants devient alors indispensable afin de garder des jetons valides pendant les analyses automatisées.
Quelques bonnes pratiques facilitent la mise en œuvre :
Profondeur des tests équilibrée : des tests exhaustifs sont utiles, mais une analyse agressive dégrade parfois les performances en production. Elle risque aussi de déclencher les protections du WAF et des passerelles d’API. Privilégiez la préproduction et des profils d’analyse sans risque pour la production, sur des fenêtres de maintenance convenues.
Gestion des données de test : utilisez des données synthétiques plutôt que de vraies données clients. Vous évitez ainsi toute fuite de données personnelles pendant les tests.
Sécurité shift-left : permettez aux développeurs de lancer des analyses tôt dans leur flux de travail. Ils corrigent ainsi les problèmes avant la fusion du code.
Les API évoluent vite : votre analyse doit suivre le rythme. Le versioning laisse parfois derrière lui des « API zombies », c’est-à-dire d’anciennes versions toujours actives et vulnérables.
Misez sur l’analyse automatisée pour une couverture large et une surveillance continue. Les tests manuels ciblés valident la logique métier et les scénarios d’abus qui échappent parfois aux outils automatisés.
Planifiez des analyses fréquentes de vos API critiques. Définissez des politiques de sécurité claires qui fixent les seuils de risque acceptables avant tout déploiement. Les bons outils de test de sécurité des API vous aident à automatiser cette gouvernance.
L’analyse des API facilite le respect de plusieurs cadres de conformité. Elle démontre en effet la surveillance continue de la sécurité et la mise en œuvre du vulnerability management. Pour SOC 2, elle fournit des preuves des contrôles de surveillance de la sécurité (CC7.1) et des processus de vulnerability management (CC7.2).
Des tests réguliers des API satisfont aussi deux exigences d’ISO 27001. La première porte sur le cycle de développement sécurisé (A.14.2), la seconde sur le vulnerability management technique (A.12.6). Les tests d’autorisation des API renforcent les mesures de protection techniques HIPAA relatives aux contrôles d’accès (§164.312(a)).
L’exigence 6.6 de PCI DSS impose soit un pare-feu applicatif web, soit des tests de sécurité des applications. L’analyse des API remplit l’option des tests pour les API de paiement. Conservez les rapports d’analyse, les délais de remédiation et les validations d’exceptions afin de prouver votre conformité lors des audits.
Prioriser et corriger les failles détectées dans les API
Impossible de corriger toutes les vulnérabilités immédiatement : vous devez donc prioriser selon les chemins d’attaque réels. La priorisation par graphe relie les résultats d’analyse des API au contexte de l’infrastructure cloud, dans un security graph unifié. Ce contexte couvre l’exposition à Internet, les permissions d’identité et la sensibilité des données.
Prenons une vulnérabilité d’injection dans une API uniquement interne. Ses comptes de service respectent le principe du moindre privilège (PoLP) et elle n’accède qu’à des données non sensibles. La faille reste alors peu prioritaire.
Le scénario change du tout au tout si l’API est exposée à Internet et s’exécute avec des identifiants administrateur. Si elle interroge en plus des databases d’informations PII clients, la même faille devient critique. Cette approche contextuelle réduit l’alert fatigue, car la remédiation se concentre sur les vulnérabilités qui ouvrent de véritables chemins d’attaque.
En clair, une faille dans une application de test interne pèse moins que la même faille dans une API de paiement publique.
Plusieurs stratégies rendent la remédiation plus efficace :
Corréler les risques : reliez les failles des API au contexte de l’infrastructure (exposition à Internet, permissions d’identité, sensibilité des données) afin de visualiser le chemin d’attaque complet. Une vulnérabilité de sévérité moyenne devient par exemple critique sur une API exposée à Internet. C’est le cas si ses comptes de service ont des privilèges excessifs et si elle accède à des informations PII clients.
Identifier les combinaisons toxiques : repérez les cas où plusieurs problèmes mineurs se combinent en un chemin d’attaque critique.
Remonter jusqu’au code : choisissez des outils qui relient les résultats runtime à la ligne précise du code source.
Sans responsable clairement désigné, la correction traîne. La corrélation code-to-cloud remonte les problèmes d’API runtime jusqu’aux code repositories et à leurs propriétaires. Vous corrigez ainsi à la source.
Les plateformes modernes relient chaque endpoint d’API à son origine : code repository Git, CI/CD pipeline et équipe de développement. Vous créez alors automatiquement des tickets Jira assignés à la bonne équipe. Chaque ticket renvoie vers les fichiers et les lignes de code précis à corriger.
Intégrez les résultats directement dans vos outils de ticketing existants. Vous fluidifiez ainsi le processus et réduisez le délai moyen de remédiation (MTTR).
Fixez des accords de niveau de service (SLA) de remédiation selon la sévérité. Exigez par exemple la correction des vulnérabilités critiques sous 24 heures. Validez toujours chaque correctif par une nouvelle analyse, afin de confirmer que la vulnérabilité est bien résolue.
Dernière étape : mesurer vos progrès. Suivez des indicateurs comme le délai de remédiation et montrez l’amélioration de la posture de sécurité de vos API.
L’approche de Wiz pour une sécurité complète des API
Wiz API Security Posture Management (API SPM) apporte une capacité unifiée de sécurité des API au sein de la plateforme de sécurité cloud de Wiz. La solution découvre automatiquement les API de votre cloud environment.
Elle s’appuie pour cela sur le Wiz Runtime Sensor, l’analyse de la surface d’attaque externe et les spécifications d’API. Vos équipes gardent ainsi la visibilité sur un parc d’API en constante évolution.
La plateforme relie ensuite les vulnérabilités et les écarts de posture des API au contexte cloud via le Wiz Security Graph. Vous voyez ainsi comment un problème d’API se rattache à l’exposition à Internet, aux identités, aux données sensibles et aux services en aval. Ce point compte encore plus dans les applications dotées d’IA, où les API connectent modèles, agents et datastores.
C’est sur cette vision d’ensemble de la posture que Wiz API SPM apporte une vraie valeur, bien au-delà d’une analyse ponctuelle. La solution tient à jour en continu un inventaire des API gérées, non gérées, fantômes et zombies. Elle y associe le contexte d’authentification et de données sensibles.
Vos équipes repèrent ainsi les dérives et répondent aux exigences de conformité. Elles concentrent aussi l’analyse sur les API réellement exposées.
Principales capacités de Wiz :
Penetration testing autonome : le Wiz Red Agent sonde de manière proactive la logique applicative. Il valide des vulnérabilités d’API complexes en plusieurs étapes.
Corrélation code-to-cloud : Wiz remonte les problèmes d’API runtime jusqu’au propriétaire et au code source concernés. Les corrections sont ainsi plus rapides.
Analyse dynamique : la plateforme valide l’exposition externe et enrichit les résultats avec le contexte cloud interne.
Analyse unifiée des chemins d’attaque : les risques liés aux API s’intègrent à la vision d’ensemble des menaces de sécurité cloud.
La sécurité des API gagne en clarté lorsque les vulnérabilités sont reliées à leur contexte cloud. Découvrez lors d’une démonstration comment Wiz aide vos équipes à identifier les risques prioritaires et à corriger les problèmes à la source. Voir Wiz en action
Démo
La démonstration de Wiz montre comment relier les vulnérabilités des API au contexte cloud pour prioriser les corrections.
