chaque pull request L'ajout ou la modification d'un point de terminaison accroît la surface d'attaque de votre API. La plupart des outils de sécurité des API ne le détectent que lorsque ce point de terminaison est en production et reçoit déjà du trafic. À ce stade, la correction ne se limite plus à une simple modification de code lors d'une revue de code ; elle nécessite une discussion dans le cadre d'une réponse à l'incident.
La sécurité des API consiste à identifier et à corriger les risques liés à la manière dont une application expose ses points de terminaison : qui peut les appeler, quelles données ils renvoient et s’ils fonctionnent comme indiqué dans la documentation.
La plupart des outils conçus pour résoudre ce problème testent l'API en cours d'exécution, de l'extérieur, comme le ferait un attaquant. Cette approche fonctionne, mais seulement après le déploiement de l'API. Xygéni Il emprunte la voie précédente : il lit votre code source et votre spécification d’API avant même qu’une seule requête n’atteigne le point de terminaison.
Les quatre façons de tester une API et ce que chacune révèle
La plupart des programmes matures exécutent plusieurs de ces éléments :
- Essais statiques Elle analyse le code source et les spécifications de l'API avant le déploiement. Elle répond à la question : « Qu'avons-nous exposé ? » C'est cette approche que cet article aborde.
- Tests dynamiques (DAST) Il envoie du trafic réel à une API en fonctionnement et observe sa réaction. Il répond à la question : « Qu'est-ce qui est réellement accessible et exploitable actuellement ? »
- Fuzzing Il génère des entrées malformées ou inattendues aux points de terminaison afin de mettre en évidence les plantages et les défaillances dans des cas limites. Il répond à la question : « Quelles sont les erreurs qui surviennent avec des entrées imprévues ? »
- Tests d'intrusion manuels Il ajoute un jugement humain pour déceler les failles logiques que les outils automatisés ne détectent pas. Il répond à la question : « Quelles actions un attaquant intelligent enchaînerait-il ? »
Aucun de ces programmes ne remplace les autres. Ils répondent à des questions différentes à différents moments du cycle de vie, et la lacune la plus fréquente concerne le premier point.
Pourquoi la plupart des outils de sécurité des API détectent le risque trop tard
Les tests de sécurité des API en cours d'exécution envoient du trafic à une application en production et observent sa réponse. Il s'agit d'une couche légitime et nécessaire. Par construction, c'est aussi un indicateur retardé : un point de terminaison doit exister, être déployé et accessible avant qu'un scanner en cours d'exécution puisse fournir des informations à son sujet. Tout ce qu'il détecte était déjà exposé pendant la durée de l'analyse.
Il existe une seconde lacune sous-jacente à ce problème de synchronisation. Les outils d'exécution ne peuvent tester que ce dont ils connaissent l'existence. Si un point de terminaison n'a jamais été documenté, ou si la spécification OpenAPI est devenue obsolète dès qu'une nouvelle route a été déployée, un outil d'analyse d'exécution est incapable de savoir qu'il existe. Il teste la carte, pas le territoire.
Les tests de sécurité statiques des API comblent ces deux lacunes en déplaçant la vérification là où le point de terminaison est défini : dans votre code et votre spécification d’API, avant le déploiement. pull request qui introduit un point final est le pull request qui met en évidence son risque.
Que signifie réellement la sécurité des API statiques ?
Xygeni construit votre inventaire d'API à partir de deux sources : le code source de votre application et vos spécifications d'API, notamment OpenAPI et Swagger.
Un inventaire basé uniquement sur les spécifications recense les points de terminaison documentés. Un inventaire basé uniquement sur le code montre ce qui existe, mais pas nécessairement comment cela était censé être utilisé. La lecture des deux permet d'obtenir une vue d'ensemble : les points de terminaison documentés par vos équipes et ceux qui ne l'ont pas été.
Cet inventaire constitue le fondement sur lequel tout le reste repose :
- Nombre total d'API découvertes et d'actifs à risque mesurés par rapport à une base de référence
- Points de terminaison classés par méthode HTTP
- Problèmes regroupés par service
- Chaque point de terminaison avec sa méthode, son chemin, son service, son module, son état d'authentification et son score de risque
Vos responsables techniques peuvent visualiser la structure de votre API sans ouvrir un seul ticket.
Chaque point de terminaison trouvé par Xygeni, avec sa méthode, son état d'authentification et son score de risque, a été construit à partir du code et des spécifications.
Production note Recadrez le panneau de triage IA à partir de n'importe quelle capture d'écran de sécurité API.
Conforme aux 10 principales priorités de sécurité des API OWASP
Les résultats confirment le cadre de référence que vos équipes de sécurité et vos auditeurs utilisent déjà. Xygeni détecte les risques liés à la sécurité des API OWASP. 10 premiers (2023):
Une catégorie est volontairement absente. L'API 6, Accès illimité aux flux métier sensibles, exige de comprendre ce qu'un processus métier est censé autoriser, et aucun analyseur statique ne permet de le détecter de manière fiable. Tout fournisseur prétendant le contraire vous vend une solution illusoire. Cette responsabilité incombe à votre modélisation des menaces et à vos testeurs d'intrusion.
Tous les résultats ne se valent pas : sensibilité des données et combinaisons toxiques
Une liste de résultats non structurée traite un point de terminaison de contrôle d'intégrité non authentifié de la même manière qu'un point de terminaison non authentifié renvoyant des enregistrements clients. Or, il ne s'agit pas du même problème, et un modèle de priorisation qui leur attribue le même score incite vos équipes à ignorer cette liste.
Xygeni classe les données traitées par chaque point de terminaison, en signalant les PII, PCI et PHI dans les paramètres de requête et dans les réponses, et les associe à l'état d'authentification du point de terminaison.
Le système met également en corrélation les résultats provenant d'un même point de terminaison et augmente leur niveau de gravité lorsqu'ils se cumulent. Une fuite d'informations personnelles dans une réponse constitue en soi un problème grave. La même fuite sur un point de terminaison ne nécessitant aucune authentification est critique, et la plateforme la signale comme telle, évitant ainsi à un opérateur de la détecter manuellement.
Points d'accès zombies et orphelins : la dérive entre code et spécification
Comme Xygeni analyse simultanément votre code et votre spécification d'API, il repère les divergences. Ces écarts se manifestent par trois schémas reconnaissables :
- Points de terminaison non documentés. Elles sont intégrées au code et n'ont jamais été ajoutées à la spécification.
- Points d'accès zombies. Elles sont signalées comme obsolètes ou retirées du service, mais restent accessibles.
- Points de terminaison orphelins. Aucun membre de l'équipe actuelle ne les possède.
Aucun de ces éléments n'apparaît dans un inventaire limité aux spécifications, car c'est précisément la spécification qui les exclut.
Des preuves exploitables, pas un prétexte pour enquêter.
Chaque résultat indique précisément le gestionnaire responsable : le fichier, la classe, la méthode et la ligne de code ayant introduit la faille, accompagnés du code incriminé. Chaque résultat est également accompagné de son niveau de gravité, de sa catégorie OWASP API Security Top 10, de son CWE, de l’état d’authentification du point de terminaison et du niveau de sensibilité des données concernées.
Un résultat qui se contente de mentionner un point de terminaison oblige un développeur à parcourir le code source avant même de pouvoir commencer à corriger quoi que ce soit. Un résultat qui indique la ligne de code lui permet de corriger immédiatement le problème.
Les résultats sont exportés aux formats JSON, CSV, Markdown et SARIF 2.1.0, afin qu'ils soient disponibles dans le fichier toutils que vos équipes utilisent déjà.
Le gestionnaire, la ligne et le code à l'origine de la vulnérabilité. Il ne s'agit pas d'un ticket d'enquête.
Pourquoi ce jeu existe sur une plateforme et pas sur une autre console
Xygeni exécute la sécurité des API en parallèle SAST, SCA, Secrets Security, IaC et DAST au sein d'une plateforme unique, corrélée par ASPM, au lieu de le livrer comme un outil séparé avec son propre login et son propre carnet de commandes.
C'est important car les analyses statiques et les analyses d'exécution répondent à des questions différentes concernant un même point de terminaison, et elles sont plus utiles ensemble que séparément. Les analyses statiques indiquent qu'un point de terminaison est risqué avant son déploiement. Les analyses DAST confirment ce qui est réellement accessible et exploitable une fois le point de terminaison en fonctionnement.
Répartir cela sur deux consoles revient à créer deux listes d'attente distinctes, où le risque corrélé est absent. Personne ne les rapproche, et le point de terminaison, à la fois non documenté et non authentifié, n'apparaît dans aucune des deux files.
Découvrez la véritable surface d'attaque de votre API. La sécurité des API est disponible en tant que Enterprise Il s'agit d'un module complémentaire à la plateforme Xygeni, et une analyse est effectuée sur vos propres dépôts au sein de votre propre infrastructure.
QFP
Peut-il indiquer quels points de terminaison traitent des données sensibles ?
Oui. Xygeni signale les données PII, PCI et PHI dans les paramètres et les réponses des points de résultat, et utilise cette classification pour classer les résultats en fonction de l'exposition réelle.
Peut-il fonctionner sur tous les appareils ? pull request?
Oui. L'analyse incrémentale analyse uniquement les points de terminaison qui ont changé, et le manifeste qu'elle produit peut concentrer une analyse DAST ultérieure sur ces mêmes points de terminaison, de sorte que les tests statiques et d'exécution restent alignés sur ce qui a réellement bougé.
Mon code quitte-t-il mon environnement ?
Non. Les analyses sont exécutées sur votre propre infrastructure. Seuls les résultats sont téléchargés, protégés lors du transfert et au repos.
Comment obtenir la sécurité API ?
La sécurité des API est disponible en tant que Enterprise Module complémentaire. Demandez une preuve de concept et nous définirons le périmètre du projet avec vous.
