Qu'est-ce que l'API Discovery ? Définition et méthodes

Qu'est-ce que l'API Discovery ?

L'API Discovery (découverte d'API) est le processus continu qui consiste à trouver toutes les API qu'une organisation exploite ou utilise, et à consigner chacune dans un inventaire avec un responsable, une version et un environnement. Il couvre les API documentées, les API shadow créées sans aucune revue, les API zombie officiellement abandonnées mais toujours en service, et les API tierces appelées par votre code. On ne peut ni sécuriser, ni tester, ni surveiller un endpoint dont on ignore l'existence.

Pourquoi c'est important

La documentation prend du retard, les équipes livrent vite et les anciennes versions restent en ligne. C'est le problème que l'OWASP décrit sous le nom de API9:2023 Improper Inventory Management : des attaquants passent par d'anciennes versions ou des endpoints laissés en service sans correctifs, souvent moins bien protégés. Voir la sécurité des API, les principaux risques de sécurité des API et l'API sprawl pour le contexte.

Ce n'est pas qu'un sujet de sécurité. Un inventaire indique qui est responsable d'un endpoint, quelles versions sont encore utilisées et ce qu'on peut retirer.

Comment ça fonctionne

Aucune source ne voit tout, donc les équipes en combinent plusieurs :

• Analyse du trafic. Observer les requêtes réelles sur une passerelle, un proxy ou un point de capture réseau. On y trouve les endpoints réellement utilisés, même non documentés.
• Journaux de la passerelle et du répartiteur de charge. Un point de départ économique si l'essentiel du trafic passe par un seul endroit.
• Analyse du code et des dépôts. Les routes déclarées dans le code révèlent des endpoints qui existent sans encore recevoir de trafic.
• Inventaire cloud et Kubernetes. Fonctions, routes d'ingress et services listés par la plateforme elle-même.
• Agrégation des spécifications. Regrouper dans un catalogue les fichiers OpenAPI (Swagger) déjà publiés par chaque équipe. Cela s'accorde bien avec une démarche API-first.
• Suivi des appels sortants. Savoir quelles API externes appellent vos services, pour inclure aussi les dépendances tierces.

Exemple

Une équipe repère dans les journaux de sa passerelle /v1/orders, qui reçoit encore quelques centaines d'appels par jour d'une ancienne application mobile alors que l'API documentée est déjà en /v3. La découverte en fait trois actions concrètes : désigner un responsable, appliquer à la v1 les mêmes contrôles de sécurité qu'à la v3 et fixer une date de retrait.

Erreurs courantes

• En faire un audit ponctuel. Un inventaire est périmé en quelques semaines. Lancez la découverte en continu ou à intervalle régulier.
• Ne s'appuyer que sur une méthode. L'analyse du trafic ne voit pas les endpoints déployés mais inutilisés, l'analyse du code ne voit pas les routes créées à l'exécution.
• Lister sans agir. Une API shadow dans un tableur sans responsable reste une API shadow.
• Oublier les API tierces et internes. Les appels entre services et les dépendances sortantes font partie du parc.
• Ne pas classer. Savoir qu'il y a 400 endpoints est moins utile que de savoir lesquels traitent des données personnelles.

Après la découverte : tester et surveiller

Une API découverte n'est qu'un nom tant que rien ne la vérifie. Une fois un endpoint inventorié, placez-le sous surveillance d'API pour être prévenu des pannes et des ralentissements avant vos utilisateurs. La surveillance d'API de LoadFocus peut importer une spécification OpenAPI 3.x ou Swagger 2.0 (JSON ou YAML, collée ou chargée depuis une URL) et crée un moniteur par opération. Elle ne découvre pas les endpoints d'elle-même : la spécification doit venir de votre propre catalogue. Pour les tests de charge, voir transformer cURL, HAR, Postman ou OpenAPI en test de charge.

Questions fréquentes : API Discovery

Pourquoi la documentation ne suffit-elle pas ?

La documentation ne contient que ce que quelqu'un a pensé à écrire. Les API shadow en sont absentes par définition, et les anciennes versions survivent souvent à leurs pages. La découverte regarde ce qui tourne réellement.

Quelle différence entre une API shadow et une API zombie ?

Une API shadow n'a jamais été revue ni enregistrée. Une API zombie est officiellement abandonnée mais reçoit encore du trafic. Les deux sont non gérées et sont des sources fréquentes d'exposition sans correctifs.

En quoi l'API Discovery diffère-t-elle d'un catalogue d'API ?

La découverte trouve ce qui existe. Le catalogue est la liste maîtrisée avec responsables, versions et documentation. La découverte garde le catalogue à jour.

À quelle fréquence la lancer ?

En continu si possible, sinon au moins chaque jour ou chaque semaine. Une revue manuelle trimestrielle laisse des trous de plusieurs mois.

LoadFocus découvre-t-il mes API ?

Non. LoadFocus teste et surveille les endpoints que vous lui indiquez, et peut créer des moniteurs à partir d'une spécification OpenAPI ou Swagger que vous fournissez.