API10 Unsafe Consumption of APIs
devsecopsDéfinition
API10 Unsafe Consumption of APIs est le dixième risque de l'OWASP API Security Top 10 (2023), traitant des vulnérabilités qui surviennent quand une API consomme des données provenant d'autres APIs tierces ou partenaires de manière non sécurisée. Ce risque illustre une réalité des architectures microservices modernes : la sécurité d'une API n'est plus uniquement déterminée par son propre code, mais aussi par la manière dont elle traite les données provenant des APIs qu'elle consomme. L'idée fondamentale de l'API10 est que les APIs tierces intégrées peuvent être des sources de données non fiables, même si elles appartiennent à des partenaires de confiance. Un partenaire peut être compromis, peut retourner des données malveillantes (injection, XSS payloads, données oversized), ou peut avoir des contrats de données différents de ceux attendus. Une API qui traite les données de ses partenaires API avec la même confiance que ses propres données internes est vulnérable. Les manifestations de l'API10 incluent : une API qui récupère des données d'un service tiers et les stocke directement en base de données sans validation (injection SQL si le service tiers est compromis), une API qui génère du contenu HTML/JavaScript à partir de données tierces sans échappement (XSS stocké), une API qui effectue des redirections vers des URLs retournées par un service tiers sans validation (open redirect), et une API qui accepte des payloads d'une taille ou d'un format non anticipé depuis un service partenaire (DoS, parsing error). La remédiation de l'API10 requiert d'appliquer les mêmes mesures de validation et de sanitization aux données provenant d'APIs tierces qu'aux données provenant d'utilisateurs finaux non fiables : validation du schéma, limitation de taille, échappement du contenu, et isolation des données tierces avant tout traitement ou stockage.
Traiter les APIs tierces comme des sources non fiables
L'API10 impose d'appliquer aux données provenant d'APIs tierces le même niveau de méfiance qu'aux entrées utilisateur directes. Un partenaire API peut être compromis à tout moment, et les données qu'il retourne peuvent contenir des injections SQL, des XSS payloads, ou des données malformées. La validation côté consommateur est donc nécessaire même pour les APIs partenaires "de confiance" : validation du schéma JSON (taille des champs, types, format), validation des URLs retournées (avant redirection ou fetch), et échappement systématique avant affichage ou stockage.
Validation du contrat d'API tiers
Un test de contract (Consumer-Driven Contract Testing) vérifie que l'API tierce respecte le contrat attendu. Des outils comme Pact permettent de définir et vérifier les contrats entre consommateurs et producteurs d'APIs. Si l'API tierce retourne soudainement un champ String là où un Integer est attendu, ou un tableau de 10 000 éléments là où 100 maximum est habituel, la validation du contrat détecte et rejette ces réponses anormales avant qu'elles n'affectent le système consommateur.
Isolation et sandboxing des données tierces
Pour les APIs consommant des sources tierces à haut risque (marketplaces, flux RSS/Atom, résultats de recherche web), des patterns d'isolation réduisent le blast radius d'une compromission : traitement des données tierces dans des workers isolés (sandboxing), stockage dans des tables séparées avant normalisation et copie en production, et validation asynchrone permettant un second niveau de vérification avant utilisation. Cette isolation évite qu'une API tierce compromise ne serve de vecteur d'injection directe dans les systèmes de production.
Articles liés
Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.
Services
- Audit Infrastructure
- Audit Kubernetes
- Audit Microsoft 365
- Audit Sécurité Réseau
- Analyse de Risques
- Audit Active Directory
- Audit Application Web
- Audit Cloud (AWS/Azure/GCP)
- Audit Messagerie
- Audit API (OWASP Top 10)
- Audit DevSecOps & CI/CD
- Audit Code Source (SAST)
- Audit Postes de Travail
- Audit Sauvegarde & Résilience
- Audit OT/SCADA (IEC 62443)
- Développement IA
- Formations
Ressources
Projets & Outils
© 2026 Ayi NEDJIMI Consultants. Tous droits réservés.
Un projet cybersécurité ?
Expert dispo · Réponse 24h