La OpenAPI Specification (OAS) (anciennement Swagger Specification) est une méthode permettant de décrire et de créer de la documentation pour les API REST, ainsi que pour leurs composants tels que les détails des points de terminaison, leurs opérations, les paramètres requis, les réponses attendues pour chaque opération, les méthodes d'authentification et les annotations. L'OAS est un format facile à apprendre et à lire, exploitable aussi bien par les humains que par les machines, ce qui le rend adapté à de nombreux cas d'usage. Dans cet article, nous aborderons la manière dont les équipes de développement et de sécurité utilisent l'OAS et pourquoi cette solution atteint ses limites en matière de sécurisation des API.
Comment les développeurs utilisent l'OAS
Les développeurs utilisent l'OAS pour générer de la documentation pour les API, sous forme de fichiers de spécification ou de définition OpenAPI. Cette documentation aide les tiers à comprendre la structure et les fonctionnalités de l'API, ce qui est utile lorsqu'un développeur souhaite intégrer une API pour enrichir son application.
Beaucoup de développeurs entretiennent une relation amour-haine avec l'OAS, car le temps consacré à la documentation est du temps perdu sur le développement. Bien que l'OAS soit facile à apprendre, la documentation est une tâche intrinsèquement fastidieuse : elle est manuelle, chronophage et constitue l'une des parties les moins gratifiantes du travail de développeur. Par conséquent, les développeurs font généralement le strict minimum, laissant la documentation incomplète, inexacte ou, dans le pire des cas, inexistante.
Comment la sécurité utilise l'OAS
La documentation OAS aide les équipes de sécurité à découvrir l'existence d'une API et à comprendre son rôle. Grâce à cette documentation, les équipes de sécurité peuvent déterminer si l'API est conforme aux politiques de l'entreprise. Par exemple, la sécurité peut utiliser la documentation pour vérifier que l'équipe de développement a correctement implémenté l'authentification et l'autorisation, et qu'elle n'expose pas inutilement des données sensibles telles que des informations personnellement identifiables (PII).
Les équipes de sécurité peuvent également utiliser des outils de sécurité basés sur l'OAS pour s'aligner sur les intentions des développeurs, en validant les entrées de l'API selon les définitions du fichier OpenAPI et en appliquant les politiques de sécurité.
Utiliser l'OAS pour la découverte d'API et la validation des politiques
Dans un monde idéal, chaque API est parfaitement documentée dans le cadre du processus de développement. La sécurité est informée de la documentation et de l'API avant sa mise en production, ce qui lui permet d'évaluer les détails, de valider la conformité de l'API et d'approuver son déploiement. Comme nous ne vivons pas dans un monde idéal, posez-vous les questions suivantes :
La documentation OAS existe-t-elle ? Dans les cas les plus extrêmes, la documentation n'existe pas, ce qui empêche toute forme de visibilité. L'entreprise se retrouve alors avec des API fantômes et des risques non identifiés.
La documentation OAS est-elle complète ? Dans tous les environnements que nous avons observés ? Non. Nos clients produisent leur documentation avec confiance, mais lorsque notre plateforme analyse le même environnement, la documentation ne correspond pas à la réalité. Les écarts vont d'une documentation incomplète à l'absence de détails critiques, comme le montre l'exemple suivant, où la documentation OAS (Swagger) indiquait 2 paramètres alors que nous en avons trouvé 27 :
En plus de l'omission de 25 paramètres, la documentation OAS manquait d'informations clés sur l'exposition de données PII, laissant l'entreprise vulnérable.
La documentation OAS est-elle tenue à jour ? Les pratiques de développement rapide impliquent que les API évoluent constamment, et la mise à jour de la documentation accuse toujours un retard.
Utiliser des outils de sécurité basés sur l'OAS pour sécuriser les API
Les entreprises peuvent également utiliser la documentation OAS comme schéma pour valider les entrées API, en appliquant un outil de sécurité basé sur OAS pour garantir que les données saisies sont conformes aux définitions du fichier OpenAPI. Par exemple, le fichier de définition OpenAPI peut spécifier qu'un paramètre doit être une chaîne de caractères, que celle-ci ne doit pas dépasser une certaine longueur et qu'elle ne doit contenir que des lettres et des chiffres, sans caractères spéciaux. Tout ce qui ne respecte pas cette définition sera bloqué.
Une documentation OAS inexistante, inexacte ou obsolète complique l'inventaire et la découverte des API, mais elle représente surtout un risque majeur pour l'application des mesures de sécurité.
Se reposer uniquement sur la documentation OAS pour la sécurité, même lorsqu'elle est précise, ne couvre qu'une infime partie des risques liés aux API et ne permet donc pas de prévenir les violations d'API ou les pertes de données. S'appuyer exclusivement sur la documentation OAS peut également nuire à vos clients, à vos partenaires et à vos activités commerciales, y compris à vos sources de revenus, en bloquant du trafic légitime.
Voici les risques liés à l'utilisation de la documentation OAS pour sécuriser vos API :
Les outils de sécurité basés sur OAS ne peuvent pas protéger contre les menaces API les plus courantes et les plus critiques. L'OAS ne comprend pas la logique des API ; il est donc impossible de créer des politiques dans un fichier de définition OpenAPI pour prévenir les attaques ciblant cette logique, comme les principales menaces définies dans le OWASP API Security Top 10.
Les outils de sécurité basés sur OAS peuvent être trompés et contournés. L'OAS manque de contexte sur l'activité globale des attaquants et ne peut donc bloquer qu'un appel API spécifique, et non l'attaquant lui-même, ce qui permet à ces derniers de multiplier les tentatives pour contourner la validation de schéma basée sur OAS.
Les outils de sécurité basés sur OAS risquent de bloquer du trafic légitime. L'application d'une technique de validation stricte bloque tout appel API anormal, y compris les incohérences de format de paramètres, les paramètres inconnus ou les points de terminaison non répertoriés. Cette approche entraîne le blocage de trafic légitime lorsque les API sont mal documentées.
Les outils de sécurité basés sur OAS risquent de laisser passer des attaques. L'application d'une technique de validation souple avec un contrat générique et très large, comme l'absence de définition de modèles ou l'utilisation de types de données vagues tels que « string », permettra à de nombreux appels API malveillants de passer outre la validation.
Conclusion
La documentation basée sur OAS est utile aux équipes de développement et de sécurité si elle est précise, mais l'OAS et les outils de sécurité qui en découlent présentent des lacunes inhérentes qui limitent la protection à une faible fraction des risques liés aux API. Se fier à la documentation OAS et aux outils de sécurité associés ne suffira pas à prévenir les violations d'API ou les pertes de données.
Découvrez comment Salt Security peut vous aider à améliorer vos efforts de documentation API basée sur OAS et assurer une couverture complète des menaces API.