Zombie API

devsecops

Définition

Une Zombie API est un endpoint d'API qui est encore techniquement accessible mais qui devrait être décommissionné car son usage est obsolète, sa documentation n'existe plus, ou elle a été remplacée par une version plus récente sans que l'ancienne version ait été supprimée. Contrairement aux Shadow APIs (jamais officiellement gérées), les Zombie APIs ont existé officiellement mais sont tombées dans un état de "mort-vivant" : toujours actives mais non maintenues. Le problème des Zombie APIs est lié au cycle de vie des APIs dans les organisations. Quand une nouvelle version d'une API est déployée (v2 remplace v1), la v1 est souvent maintenue temporairement pour la compatibilité des clients existants. Si la dépréciation et la décommission ne suivent pas un calendrier strict et rigoureux, v1 peut rester active indéfiniment, accumulent des vulnérabilités CVE dans ses dépendances non maintenues, opérant sans monitoring, et représentant une surface d'attaque non gérée. Les Zombie APIs partagent plusieurs caractéristiques. Elles ne reçoivent plus de patches de sécurité car personne ne se souvient qu'elles existent ou que c'est sa responsabilité de les maintenir. Elles peuvent utiliser des mécanismes d'authentification obsolètes ou contourner certains contrôles de sécurité plus récents appliqués aux nouvelles versions. Elles manquent souvent de monitoring et de logging appropriés, rendant leur exploitation difficile à détecter. Elles accumulent des vulnérabilités de dépendances car leurs bibliothèques ne sont pas mises à jour. La gestion du cycle de vie des APIs est la solution fondamentale : une politique formelle de dépréciation (annonce aux clients avec délai raisonnable de 6 à 12 mois), de migration (outils et guides de migration vers la nouvelle version), et de décommission (suppression effective de l'endpoint à la date annoncée) prévient l'accumulation de Zombie APIs. Des outils de gouvernance d'API (Stoplight, Kong Insomnia, Apigee Portals) facilitent la gestion du cycle de vie avec des workflows de dépréciation formalisés.

Distinguer Shadow API et Zombie API

Shadow API : n'a jamais été officiellement documentée ni gérée — créée informellement, ignorée des systèmes de gouvernance. Zombie API : a été officiellement gérée mais n'a pas été décommissionnée — version obsolète maintenue pour compatibilité, endpoint de debug non supprimé, API d'intégration d'un partenaire qui n'est plus actif. Les deux présentent des risques de sécurité similaires (non maintenues, non monitorées) mais les stratégies de prévention diffèrent.

Politique de dépréciation et décommission

Une politique de cycle de vie d'API efficace définit : la période de préavis de dépréciation (6-12 mois minimum), les communications aux clients (changelog, emails, headers Deprecation et Sunset dans les réponses API selon la RFC 8594), les métriques de suivi de l'usage de la version obsolète (objectif : zéro appel avant décommission), et la date de décommission ferme après laquelle l'endpoint retourne 410 Gone puis est supprimé. Les sunset headers permettent aux clients de détecter automatiquement la dépréciation imminente.

Détection des Zombie APIs dans les environnements existants

Pour identifier les Zombie APIs existantes : analyser les logs d'accès pour identifier les endpoints avec un trafic décroissant ou nul, comparer l'inventaire des API Gateways avec la documentation officielle, scanner les services Kubernetes/ECS actifs pour identifier des déploiements sans propriétaire documenté, et interviewer les équipes sur les APIs créées pour des projets terminés. Un "API health check" annuel systématique dans les grandes organisations révèle systématiquement des dizaines de Zombie APIs.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis