Gestion de la posture de sécurité des API : découverte, tests et gouvernance des risques en continu

Les API constituent une partie critique de la surface d'attaque de l'entreprise. Elles connectent les applications web, les applications mobiles, les microservices, les services cloud, les intégrations partenaires, les portails clients, les flux de travail IA, les outils internes et les systèmes métier backend. Dans de nombreuses organisations, les API traitent des transactions commerciales sensibles et des données clients.

Cette croissance crée un problème de visibilité et de gouvernance. La plupart des entreprises ne peuvent pas répondre avec certitude aux questions fondamentales sur la sécurité des API :

• Combien d'API possédons-nous ?
• Quelles API sont publiques, internes, destinées aux partenaires ou exclusivement mobiles ?
• Quelles API ne sont pas documentées, sont obsolètes ou n'ont plus de responsable ?
• Quelles API présentent des vulnérabilité confirmées et exploitables ?
• Quelles API exposent des données sensibles ?
• Quelles équipes sont responsables de la remédiation ?

La gestion de la posture de sécurité des API est la discipline qui permet de répondre continuellement à ces questions.

Elle permet à la sécurité des API de dépasser le stade des inventaires statiques, des tests occasionnels et des résultats isolés. Au lieu de cela, elle offre aux équipes de sécurité une vue actuelle de l'exposition des API, de la couverture des tests, des vulnérabilités confirmées, des risques métier, de la propriété, de l'état de remédiation et des tendances de la posture sur l'ensemble du parc d'API.

Ceci est crucial car de nombreuses vulnérabilités graves des API impliquent la logique d'autorisation, les contrôles d'accès au niveau des objets, les limites entre locataires, le comportement d'authentification, les flux de travail métier, les limites de ressources, l'exposition de données sensibles, les versions obsolètes et les points de terminaison non documentés. La documentation et les spécifications seules ne peuvent pas révéler pleinement ces risques.

Les API doivent être découvertes, testées, validées, priorisées, assignées, corrigées et retestées.

Qu'est-ce que la gestion de la posture de sécurité des API ?

La gestion de la posture de sécurité des API est la pratique continue consistant à découvrir les API, à évaluer leur exposition, à les tester pour détecter des vulnérabilités exploitables, à prioriser les risques en utilisant le contexte technique et métier, et à acheminer les résultats vers les équipes responsables de la remédiation.

Un programme mature de gestion de la posture de sécurité des API fournit une vue continuellement mise à jour des éléments suivants :

• API connues
• API fantômes
• API obsolètes ou zombies
• Points de terminaison authentifiés et non authentifiés
• API publiques, partenaires, internes et mobiles
• REST, GraphQL, SOAP et autres API web
• Couverture des tests d'API
• Vulnérabilités confirmées
• Résultats liés à une autorisation défaillante au niveau de l'objet
• Résultats liés à une autorisation défaillante au niveau de la fonction
• Faiblesses d'authentification
• Exposition de données sensibles
• Risques liés à la consommation de ressources et à la limitation de débit
• Responsables des API
• Statut de remédiation
• Performance des accords de niveau de service
• Tendances des risques dans le temps

L'objectif n'est pas simplement de scanner les API. Il s'agit de rendre la sécurité des API mesurable et gérable en tant que risque métier continu.

Gestion de la posture de sécurité des API vs gestion de la posture de sécurité des applications

Gestion de la posture de sécurité des applications (ASPM) est la discipline plus large consistant à agréger, corréler, prioriser et gérer les résultats de sécurité des applications à travers les outils, les équipes et les environnements. La gestion de la posture de sécurité des API peut être considérée comme l'application spécifique aux API de cette discipline.

L'ASPM général aide à répondre à des questions telles que :

• Quelles applications présentent le plus de risques ?
• Quelles vulnérabilités ont été validées ?
• Quelles sont les vulnérabilités en double ?
• Quelles équipes ne respectent pas les SLA de remédiation ?
• Quelles applications manquent d'une couverture de test adéquate ?

La gestion de la posture de sécurité des API ajoute des questions spécifiques aux API :

• Quelles API existent, y compris les API non documentées ?
• Quels points de terminaison nécessitent une authentification ?
• Quelles API exposent des données sensibles ?
• Quelles API sont vulnérables à une faille d'autorisation au niveau de l'objet (BOLA)?
• Quelles API sont vulnérables à une faille d'autorisation au niveau de la fonction (BFLA) ?
• Quelles versions d'API obsolètes restent accessibles ?
• Quelles API n'ont pas de responsable ?
• Quelles vulnérabilités d'API ont été validées par des tests d'exécution ?

Cette distinction est importante car le code source, la documentation et la configuration de la passerelle ne donnent qu'une vision partielle. Le risque lié aux API découle souvent du comportement d'une API en cours d'exécution lorsque différents utilisateurs, rôles, jetons, objets et flux de travail interagissent.

Pourquoi la gestion de la posture de sécurité des API est importante

Les programmes de sécurité des API échouent lorsqu'ils dépendent d'inventaires statiques et d'évaluations ponctuelles.

Les équipes de développement déploient les API rapidement. Les microservices changent fréquemment. Les applications mobiles introduisent des points de terminaison backend qui peuvent ne pas apparaître dans les inventaires web classiques. Les intégrations tierces créent de nouveaux flux de données. Les API internes peuvent devenir accessibles de l'extérieur après des modifications de routage ou de passerelle. Les versions obsolètes peuvent rester en ligne parce qu'un partenaire ou un système hérité en dépend toujours.

Le résultat est la prolifération des API, ce qui devient dangereux lorsque les équipes de sécurité ne peuvent pas voir quelles API existent, si elles ont été testées, quelles données elles exposent, qui en est responsable, ou si les vulnérabilité identifiées ont été corrigées et retestées.

Les lacunes courantes en matière de posture des API incluent :

• Les API fantômes omises de l'inventaire officiel
• Les API zombies qui restent accessibles après leur dépréciation
• Les API partenaires en dehors du périmètre de test habituel
• Les API backend mobiles absentes des tests d'applications web
• Les API internes exposées par des erreurs de routage ou de passerelle
• Les points de terminaison GraphQL avec des capacités de requête excessives
• Les API authentifiées jamais testées sur plusieurs utilisateurs ou rôles
• Les API publiques sans responsable actuel
• Les vulnérabilité d'API fermées sans vérification par retest

La gestion de la posture de sécurité des API aide à combler ces lacunes en combinant découverte continue, tests dynamiques, priorisation basée sur les risques, attribution des responsabilités, intégration des flux de travail et retest.

Les quatre composants essentiels de la gestion de la posture de sécurité des API

Un programme pratique de gestion de la posture de sécurité des API comporte quatre composants essentiels :

1. Découverte continue des API
2. Tests de sécurité continus des API
3. Score de risque et priorisation des API
4. Cartographie des responsabilités et gouvernance de la remédiation

Chaque composant est nécessaire. La découverte sans test produit un inventaire sans visibilité sur les risques. Les tests sans responsable créent des résultats que personne ne corrige. Le score de risque sans preuve d'exploitabilité peut amener les équipes à prioriser des suppositions. La responsabilité sans découverte continue laisse des API inconnues en dehors du programme.

Composant 1 : Découverte continue des API

La posture des API commence par l'inventaire, car les équipes de sécurité ne peuvent pas gérer des API dont elles ignorent l'existence. La découverte d'API doit combiner plusieurs sources et méthodes, telles que :

• Fichiers OpenAPI et Swagger
• Collections Postman
• Passerelles d'API
• Trafic réseau
• Découverte basée sur le DAST
• Exploration d'applications web
• Analyse JavaScript
• Dépôts de code
• Trafic d'applications mobiles
• Données Kubernetes et d'exécution
• Télémétrie de maillage de services
• Métadonnées cloud et d'infrastructure
• Systèmes CI/CD

Différentes méthodes de découverte d'API doivent être utilisées conjointement, car aucune source unique ne fournit une vue complète :

Un programme mature de gestion de la posture de sécurité des API combine ces méthodes, corrèle les résultats, supprime les doublons et maintient un inventaire d'API unifié. 

Une cible particulièrement importante est l'API fantôme.

Les API fantômes sont des points de terminaison qui existent en dehors de toute documentation, propriété ou examen de sécurité formel. Une équipe de développement peut les avoir déployés en dehors des processus approuvés. Une application mobile peut les exposer. Une intégration tierce peut les introduire. Il peut également s'agir d'anciens points de terminaison qui n'ont jamais été correctement mis hors service.

Un programme de posture basé uniquement sur des inventaires gérés manuellement laissera échapper certaines de ces API. Une découverte continue et multicouche réduit cet angle mort.

Composant 2 : Test de sécurité continu des API

La découverte vous indique ce qui existe. Le test vous indique où de réelles faiblesses de sécurité peuvent être présentes.

Une API découverte mais non testée a une posture de sécurité inconnue. Elle peut être correctement protégée, ou elle peut exposer des données sensibles, permettre un accès inter-utilisateurs, ne pas appliquer l'authentification, autoriser l'abus de ressources ou conserver des fonctionnalités obsolètes vulnérables.

Le test de sécurité des API doit traiter les principales catégories de risques liés aux API, notamment :

• Autorisation défaillante au niveau de l'objet
• Authentification défaillante
• Autorisation défaillante au niveau des propriétés de l'objet
• Consommation de ressources sans restriction
• Autorisation défaillante au niveau de la fonction
• Accès sans restriction aux flux métier sensibles
• Falsification de requête côté serveur
• Mauvaise configuration de sécurité
• Gestion inappropriée de l'inventaire
• Consommation non sécurisée d'API

Bon nombre de ces risques nécessitent un test dynamique d'une API en cours d'exécution, les tests authentifiés et autorisés étant particulièrement importants pour identifier les vulnérabilités BOLA et BFLA.

Le test BOLA nécessite généralement plusieurs sessions authentifiées au même niveau de privilège. Le scanner ou le testeur identifie un objet associé à un utilisateur, puis vérifie si un autre utilisateur peut accéder à cet objet en substituant les identifiants entre les sessions.

Le test BFLA nécessite des comptes avec des privilèges ou des rôles différents. Le scanner ou le testeur tente d'accéder à des fonctions, des points de terminaison ou des méthodes HTTP restreints en utilisant un compte à privilèges inférieurs et vérifie si l'API applique l'autorisation au niveau de la fonction.

Ces deux classes de vulnérabilité opèrent à des niveaux différents. La BOLA concerne la capacité d'un utilisateur à accéder à un objet spécifique. La BFLA concerne la capacité de l'utilisateur à invoquer une fonction. Tester un seul niveau peut laisser l'autre exposé.

D'autres risques dépendent également du comportement à l'exécution. Les tests de consommation des ressources consistent à envoyer des requêtes et à observer la réponse de l'API. Les tests d'authentification peuvent inclure des vérifications sur la gestion des jetons, l'expiration, la relecture et les portées. Les tests hors bande peuvent utiliser une infrastructure de rappel contrôlée pour confirmer certaines vulnérabilités de falsification de requête côté serveur. L'exposition de données sensibles nécessite l'observation des réponses réelles.

C'est pourquoi le DAST est essentiel à la gestion de la posture de sécurité des API. Il évalue le comportement de l'API en cours d'exécution, plutôt que de se fier uniquement à la manière dont elle a été conçue ou documentée.

Composant 3 : Scoring et priorisation des risques liés aux API

La gestion de la posture des API doit produire un inventaire des API avec une évaluation des risques, et non une simple liste de résultats. Le scoring des risques peut prendre en compte :

• Exploitabilité confirmée
• Sévérité de la vulnérabilité
• Exposition sur Internet
• Exigences d'authentification
• Exposition de données sensibles
• Criticité métier
• Propriété de l'API
• Impact client
• Impact réglementaire
• Fréquence d'utilisation
• Preuve d'exploitation connue
• Statut de remédiation
• Ancienneté du résultat
• Si l'API est obsolète
• Si l'API est documentée

Une vulnérabilité BOLA confirmée dans une API de compte client public doit être prioritaire par rapport à un problème d'en-tête de faible gravité sur un point de terminaison de test interne.

Une API obsolète qui expose toujours des données sensibles peut également nécessiter une attention urgente. Les API obsolètes ont souvent une propriété moins claire, une surveillance réduite et moins d'opportunités de maintenance régulière que les services en développement actif.

Le scoring de risque doit également distinguer les résultats potentiels des résultats validés. L'analyse du code source peut identifier un modèle susceptible de mener à une vulnérabilité. Les tests dynamiques peuvent fournir des preuves d'exécution montrant qu'un comportement vulnérable est accessible et, pour les classes de vulnérabilité prises en charge, confirmer l'exploitabilité.

Un programme de posture mature rend cette distinction visible afin que les équipes puissent concentrer leurs efforts de remédiation là où ils réduiront le plus les risques.

Composant 4 : Cartographie de la propriété et gouvernance de la remédiation

Les résultats concernant les API ne réduisent pas les risques tant que quelqu'un ne les a pas corrigés.

Chaque API doit être associée à un propriétaire. Selon l'organisation, ce propriétaire peut être une équipe de développement, une équipe plateforme, un groupe produit, une unité commerciale ou une équipe de service. Pour chaque API, la gestion de la posture doit suivre des informations telles que :

• Propriétaire technique
• Propriétaire métier
• Dépôt
• Nom du service
• Environnement
• Documentation de l'API
• Date du dernier scan
• Date du dernier déploiement
• Résultats ouverts
• SLA de remédiation
• Statut d'acceptation du risque
• Statut de retest

La cartographie de la propriété permet de résoudre l'un des problèmes opérationnels les plus persistants de la sécurité des API : les résultats orphelins.

Un scanner peut identifier une faille critique, mais la remédiation stagne lorsqu'aucune équipe n'est responsable de l'API. Les équipes de sécurité doivent alors déterminer qui a créé le service, si quelqu'un l'utilise encore, qui a l'autorisation de le modifier et quel cycle de publication peut intégrer le correctif.

La gestion de la posture des API intègre la propriété au dossier de sécurité plutôt que de la traiter comme une réflexion après coup.

Les indicateurs de posture de sécurité des API qui comptent

Un programme mature de posture des API doit mesurer bien plus que le nombre total de vulnérabilités. Les indicateurs utiles incluent :

• Nombre total d'API découvertes
• Pourcentage d'API testées
• Pourcentage d'API avec des propriétaires identifiés
• Nombre d'API fantômes découvertes
• Nombre d'API zombies toujours accessibles
• Pourcentage d'API couvertes par des scans authentifiés
• Pourcentage d'API concernées testées pour les failles BOLA et BFLA
• Vulnérabilités critiques et élevées confirmées par API
• Délai moyen de remédiation des vulnérabilités d'API
• Conformité aux SLA par équipe
• Pourcentage de résultats retestés après remédiation
• Nombre d'API exposant des données sensibles
• Nombre d'API sans documentation à jour
• Nombre d'API ajoutées depuis la période de reporting précédente
• Tendances des risques par unité commerciale

Ces indicateurs distinguent la gestion de la posture du déploiement d'outils. Un scanner signale des résultats. Un programme de posture rend compte de la couverture, de la responsabilité, du risque, de la performance de remédiation et de la progression.

Gestion de la posture de sécurité des API dans le CI/CD

La posture des API doit être mise à jour à mesure que les API évoluent. Cela nécessite l'intégration de tests de sécurité des API dans les flux de travail de développement et de déploiement de logiciels. Un flux de travail pratique pourrait ressembler à ceci :

1. Une équipe de développement modifie une API.
2. Un déploiement en environnement de staging déclenche un scan de sécurité d'API authentifié.
3. Le scanner importe une spécification ou une collection d'API, utilise une définition de trafic enregistrée ou teste les points de terminaison déjà présents dans l'inventaire des API.
4. Le scanner vérifie les risques de sécurité des API applicables.
5. Les résultats validés sont envoyés au système de suivi des tickets de l'équipe responsable.
6. Les résultats critiques confirmés peuvent bloquer la mise en production ou nécessiter une exception documentée.
7. Le re-test vérifie le correctif déployé.
8. Le tableau de bord de posture met à jour la couverture, le risque, la responsabilité et le statut SLA.

Cette approche empêche les données de posture des API de devenir obsolètes. Au lieu d'attendre une évaluation trimestrielle, les équipes peuvent mettre à jour leur vue de la sécurité à mesure que les applications et les API changent.

Erreurs courantes dans la gestion de la posture de sécurité des API

• Traiter l'inventaire des API comme la posture des API : L'inventaire n'est que le point de départ. Savoir qu'une API existe ne permet pas de savoir si elle est sécurisée, exposée, authentifiée, possédée, testée ou vulnérable.
• Dépendre uniquement des données de la passerelle API : Les passerelles API couvrent le trafic géré. Elles peuvent ignorer les API à origine directe, les services de staging, les points de terminaison internes, les API mobiles, les API partenaires, les points de terminaison obsolètes et les API déployées en dehors du chemin de la passerelle.
• Tester uniquement les API non authentifiées : De nombreux risques graves liés aux API existent derrière l'authentification. Les failles BOLA, BFLA, les échecs d'isolation des locataires, l'exposition des données de compte et les problèmes de flux de travail privilégiés nécessitent des tests authentifiés avec plusieurs utilisateurs ou rôles.
• Ignorer les API fantômes et zombies : Les API fantômes créent une exposition non gérée. Les API zombies peuvent exécuter du code obsolète et souffrent souvent d'une propriété floue, d'une surveillance limitée et de tests incomplets.
• Rapporter le nombre brut de vulnérabilités : Le nombre brut de vulnérabilités ne reflète pas la posture de sécurité. Un programme mature mesure la couverture des tests, la preuve d'exploitabilité, la propriété, la performance de remédiation et les tendances de risque.
• Omettre les retests : Fermer un ticket ne signifie pas vérifier la remédiation. Le retest permet de vérifier si l'API déployée présente toujours le comportement vulnérable.

Comment Invicti soutient la gestion de la posture de sécurité des API

Invicti soutient la gestion de la posture de sécurité des API en combinant la découverte multicouche des API, les tests de sécurité dynamiques, la validation par preuve, les tests d'autorisation authentifiés, les flux de travail de remédiation, les retests et la visibilité ASPM.

Invicti aide les équipes à :

• Découvrir les API grâce à l'analyse des applications web, l'analyse des dépôts de code, les intégrations de passerelles API, l'analyse du trafic réseau et la visibilité sur l'infrastructure et l'exécution
• Normaliser, corréler et dédupliquer les points de terminaison découverts dans un inventaire API unifié
• Tester les surfaces REST, SOAP, GraphQL et autres API web
• Exécuter des scans d'API authentifiés et avec état
• Utiliser des tests multi-sessions pour identifier les vulnérabilités BOLA
• Utiliser des tests multi-rôles pour identifier les vulnérabilités BFLA
• Valider l'exploitabilité avec des preuves pour les classes de vulnérabilités prises en charge
• Identifier les vulnérabilités et les erreurs de configuration à l'exécution
• Acheminer les résultats vers les flux de travail de développement et de remédiation
• Retester les API après remédiation
• Suivre les résultats, la propriété, les risques et la remédiation sur l'ensemble du portefeuille d'applications via l'ASPM

Une base axée sur le DAST est essentielle, car une posture API efficace nécessite des preuves issues de systèmes en cours d'exécution.

Les spécifications, l'analyse de code, les passerelles, la surveillance du trafic et la visibilité à l'exécution contribuent tous à la découverte et au contexte. Le DAST ajoute la capacité d'interagir avec les API accessibles, d'observer leur comportement réel et de valider les faiblesses de sécurité concrètes.

L'ASPM d'Invicti étend ces preuves d'exécution à l'ensemble du programme AppSec. Il centralise les résultats provenant de multiples outils, les corrèle et les déduplique, applique un contexte métier et de risque, automatise les flux de travail et suit la remédiation à travers les équipes et les applications.

Connaissez votre posture de sécurité API au quotidien

La gestion de la posture de sécurité des API consiste à maintenir une vue actualisée des API existantes, de celles qui ont été testées, de celles qui contiennent des vulnérabilités validées et des équipes responsables des risques associés.

Invicti aide à fournir cette vue en combinant la découverte d'API multicouche avec le DAST d'API authentifié, les tests BOLA multi-sessions, les tests BFLA multi-rôles, la validation par la technologie Proof-Based Scanning pour les vulnérabilités prises en charge, les flux de travail de remédiation, les retests et une visibilité ASPM au niveau du portefeuille. Pour en savoir plus :

• Lisez notre guide sur les tests BFLA.
• Découvrez comment fonctionnent les différentes méthodes de découverte d'API.
• Demandez une démo pour voir comment Invicti trouve et teste les API dans votre environnement.