Deprecated API Risk
devsecopsDéfinition
Le Deprecated API Risk (risque lié aux APIs dépréciées) désigne les vulnérabilités et risques de sécurité associés à l'utilisation ou au maintien en service d'APIs dépréciées — APIs officiellement annoncées comme obsolètes, devant être remplacées par des versions plus récentes mais qui continuent d'être utilisées par des clients internes ou externes, créant une surface d'attaque non maintenue. Les APIs dépréciées présentent plusieurs risques de sécurité spécifiques. L'absence de correctifs de sécurité : les équipes de développement arrêtent souvent d'appliquer les correctifs de sécurité aux versions dépréciées "en attente de suppression", laissant des vulnérabilités connues sans correction. La régression des contrôles de sécurité : les améliorations de sécurité implémentées dans les nouvelles versions (validation d'entrée renforcée, nouveau schéma d'authentification, chiffrement amélioré) ne sont souvent pas rétro-portées vers les versions dépréciées. L'exposition prolongée : les migrations vers de nouvelles APIs prennent du temps, maintenant les anciennes versions actives bien au-delà de la date de dépréciation prévue. Du côté consommateur, utiliser des APIs dépréciées crée également un risque : les APIs tierces dépréciées peuvent être modifiées ou supprimées sans préavis, créant des interruptions de service inopinées, ou peuvent présenter des comportements de sécurité non documentés ou différents des APIs actuelles (gestion différente des erreurs, validation moins stricte). La gestion du Deprecated API Risk requiert des processus clairs des deux côtés : du côté producteur (sunset actif, maintenance de la parité de sécurité jusqu'au sunset effectif, migration path documenté), du côté consommateur (inventaire des APIs tiers utilisées avec leur statut de dépréciation, SLA de migration défini, monitoring des avis de dépréciation des fournisseurs tiers).
Risques de sécurité spécifiques aux APIs dépréciées
Les APIs dépréciées accumulent des vulnérabilités de sécurité de plusieurs sources : 1) Correctifs non appliqués (les équipes reportent la correction car "cette API sera supprimée bientôt"). 2) Bibliothèques non mises à jour (les dépendances du service hébergeant l'API dépréciée ne sont plus mises à jour). 3) Contrôles de sécurité moins stricts (l'API v1 n'a pas les validations d'entrée introduites dans l'API v3). 4) Monitoring réduit (les équipes n'alertent plus sur les anomalies de l'API dépréciée). 5) Documentation périmée (les consommateurs utilisent des patterns non sécurisés car la documentation de sécurité n'a pas été mise à jour).
Monitoring des APIs tierces dépréciées
Les consommateurs d'APIs tierces doivent surveiller proactivement les avis de dépréciation : s'abonner aux changelogs et newsletters des fournisseurs d'API critiques, configurer des alertes sur les headers de dépréciation retournés dans les réponses (Sunset: et Deprecation: headers selon la RFC 8594), et maintenir un inventaire des APIs tierces utilisées avec leur statut et la date de fin de support annoncée. Un processus de migration déclenché 6 mois avant la date de dépréciation garantit que les migrations sont effectuées avant la suppression effective de l'API.
Sunset actif vs dépréciation passive
La différence entre "dépréciée" et "sunset active" est critique : une API "dépréciée" est marquée comme obsolète mais reste entièrement fonctionnelle (risque de sécurité). Une API en "sunset actif" suit un plan de suppression formalisé avec date annoncée, migration documentée, et countdown dans les réponses API (Sunset: Wed, 31 Dec 2025 00:00:00 GMT header). Le sunset actif établit une deadline créant un sentiment d'urgence pour les consommateurs, réduisant la durée de vie des APIs vulnérables. Sans sunset actif, les APIs "dépréciées" peuvent rester en service des années.
Ce terme vous interpelle ?
Nos experts interviennent sur toutes les thématiques de ce glossaire — pentest, conformité NIS 2 / ISO 27001, forensics, sécurité IA. Réponse sous 24h, devis gratuit et sans engagement.