Les API fantômes

À chaque audit, le même exercice : on demande le nombre d'API de l'organisation, on note la réponse, puis on va mesurer. Le rapport entre les deux chiffres est étonnamment stable, entre deux et trois. Une organisation qui déclare 80 API en expose généralement entre 150 et 250.

La différence, ce sont les API fantômes : exposées, appelées, et absentes de tout inventaire.

D'où elles viennent

Personne ne crée une API fantôme volontairement. Elles naissent de trajectoires banales :

• l'API de « l'appli mobile », exposée directement par l'équipe qui avait un délai, en contournant la plateforme « temporairement », il y a quatre ans.
• l'endpoint de debug ouvert pour un incident et jamais refermé.
• le microservice dont l'API « interne » est appelée par trois autres équipes qui l'ont trouvée dans le code.
• la version précédente, officiellement décommissionnée, réellement encore appelée par deux consommateurs oubliés.
• l'intégration SaaS qui expose un webhook entrant que personne ne surveille.

Aucun de ces cas n'est exotique. Tous existent probablement chez vous en ce moment.

Pourquoi c'est le risque numéro un

Une API fantôme cumule tout ce qu'une plateforme est censée empêcher : pas d'authentification homogène, pas de quotas, pas de journaux centralisés, pas de propriétaire joignable, pas de correctif de sécurité suivi.

Les incidents d'exposition de données les plus médiatisés de ces dernières années partagent ce motif : ce n'est pas l'API du catalogue qui fuit, c'est celle que personne ne regardait. La sécurité d'un parc se mesure sur son point le plus faible, et le point le plus faible est par construction hors catalogue.

C'est pour cela que la découverte est un pilier à part entière, et pas une commodité de portail : on ne gouverne que ce qu'on voit.

Comment les débusquer

Aucune source ne suffit seule. La cartographie fiable croise quatre regards :

1. Le trafic. Les journaux des load balancers, des reverse proxies et du DNS interne disent ce qui est réellement appelé, en HTTP, avec des chemins qui ressemblent à des API. C'est la source la plus fidèle et la moins flatteuse.
2. Le code. Les dépôts contiennent les routes exposées : un balayage des annotations et des fichiers de routing sur l'ensemble des dépôts sort une liste d'endpoints que personne n'a jamais déclarés.
3. L'infrastructure. Les objets Ingress, les API Gateway cloud, les groupes de sécurité ouverts sur 443 : l'inventaire infra révèle les chemins d'exposition, y compris ceux qui ne passent par aucune plateforme.
4. Les gens. Un entretien d'une heure par domaine métier avec la question « qui vous appelle, et qui appelez-vous ? » fait toujours remonter des flux que rien d'autre ne montrait.

Le résultat n'est pas seulement une liste. C'est un écart : catalogue déclaré contre parc constaté. Cet écart est la mesure la plus honnête de la maturité d'une plateforme, bien plus que son nombre de policies.

Et ensuite

Chaque API découverte reçoit un sort explicite, et il n'y en a que trois : intégrer à la plateforme, décommissionner avec une date, ou documenter une exception assumée avec un propriétaire. Le quatrième sort, l'oubli, est celui qu'on vient de payer pour éliminer.

Le point important est la récurrence. Une cartographie est une photographie, et le parc bouge toutes les semaines. Les organisations matures rejouent la détection en continu, en branchant la comparaison trafic contre catalogue dans leur supervision. Les autres referont l'exercice dans trois ans, et retrouveront le même rapport du simple au triple.