Une API peut être correctement sécurisée sur le papier tout en laissant une ancienne version, un environnement de staging ou un endpoint temporaire accessible depuis Internet. Ces interfaces non maîtrisées sont souvent regroupées sous le terme shadow APIs.
Une API oubliée reste une API accessible
Une application moderne peut accumuler plusieurs interfaces : API de production, anciennes versions, endpoints mobiles, services de test, interfaces d’administration ou intégrations temporaires. Le problème apparaît lorsqu’une de ces interfaces continue à répondre alors qu’elle n’est plus réellement suivie.
L’OWASP classe cette mauvaise gestion de l’inventaire parmi les principaux risques de sécurité des API. Une documentation incomplète ou obsolète peut laisser des versions plus anciennes actives avec des exigences de sécurité différentes de celles de la version courante.
Le vrai écart à surveiller
La question n’est pas seulement « quelles API avons-nous documentées ? », mais aussi « quels services répondent réellement depuis Internet aujourd’hui ? »
Pourquoi les anciennes interfaces sont sensibles
Une ancienne API n’est pas automatiquement vulnérable. Elle peut cependant avoir échappé aux améliorations appliquées depuis : authentification renforcée, limitation du nombre de requêtes, politique CORS plus stricte, journalisation, mises à jour de dépendances ou retrait d’anciens endpoints.
Le risque vient donc autant d’une vulnérabilité technique que du décalage entre ce que l’équipe pense exposer et ce qui est réellement accessible.
Le staging n’est pas forcément privé
Un environnement de test peut sembler secondaire. Pourtant, il peut utiliser des données proches de la production, partager certains services ou conserver des mécanismes d’authentification moins stricts. Un nom comme staging.example.com ou api-v1.example.com peut rester joignable longtemps après la fin d’un projet.
L’OWASP recommande d’inventorier les hôtes API, leurs versions et leur environnement — production, test, développement ou staging — et d’identifier ceux qui doivent réellement être accessibles.
Le problème dépasse les API
La même logique s’applique à toute la surface exposée : sous-domaines abandonnés, anciennes applications, interfaces d’administration, tableaux de bord, serveurs de développement ou services réseau oubliés.
Pris séparément, chacun peut sembler anodin. Ensemble, ils constituent une surface d’attaque qui peut évoluer plus vite que la documentation interne.
Construire un inventaire utile
Pour chaque API ou service exposé, il faut pouvoir répondre à quelques questions simples :
- À quoi sert-il ?
- Est-il encore nécessaire ?
- Doit-il être accessible depuis Internet ?
- Quelle version fonctionne actuellement ?
- Qui en est responsable ?
- Quand devra-t-il être retiré ou remplacé ?
Pour les API, documenter également l’authentification, les erreurs, les redirections, le rate limiting, la politique CORS et les endpoints disponibles réduit fortement le risque d’oubli.
Supprimer vaut parfois mieux que corriger
Lorsqu’un ancien service est découvert, la première question ne devrait pas toujours être « comment le sécuriser ? », mais « est-il encore utile ? ». Un endpoint inutilisé qui reste exposé ajoute du risque sans apporter de valeur. Dans ce cas, le retirer est souvent la meilleure mesure de sécurité.
Surveiller aussi ce qui apparaît
L’inventaire n’est pas un document à réaliser une seule fois. Une nouvelle application peut créer un sous-domaine, un déploiement ouvrir un service et une migration laisser l’ancien environnement en ligne.
Il faut donc pouvoir détecter ce qui apparaît, disparaît ou change avec le temps, puis comparer cette réalité à l’inventaire attendu.
Voir son infrastructure comme Internet la voit
DNS, certificats TLS, services HTTP et sous-domaines révèlent déjà une partie importante de la surface d’exposition d’une organisation. Les observer depuis l’extérieur permet de repérer un service oublié, une ancienne API, un environnement de test ou un sous-domaine inattendu.
Avant de chercher la prochaine vulnérabilité critique, une question simple mérite donc d’être posée : savons-nous vraiment tout ce que nous exposons sur Internet ?
Source
Publié le 14 septembre 2026.