OpenAPI Security Spec

Définition

OpenAPI Security Spec désigne les mécanismes de définition de la sécurité dans la spécification OpenAPI (anciennement Swagger), le standard dominant pour la documentation et la description des APIs REST. OpenAPI 3.x permet de décrire formellement les exigences de sécurité d'une API (mécanismes d'authentification, scopes OAuth, schémas de validation) dans un format machine-readable qui peut être utilisé pour générer automatiquement des configurations de sécurité, des tests, et des validations. Dans une spécification OpenAPI, la sécurité se définit à deux niveaux. Au niveau global (champ securitySchemes dans components), on définit les mécanismes d'authentification disponibles : Bearer JWT, OAuth2 avec ses flows (authorization_code, client_credentials, implicit), API Key (dans header, query ou cookie), ou HTTP Basic. Au niveau de chaque opération (endpoint), le champ security spécifie quels schémas s'appliquent à cet endpoint spécifique et, pour OAuth2, les scopes requis. La valeur de la sécurité définie dans OpenAPI dépend de son utilisation. Les outils de documentation (Swagger UI, Redoc) l'utilisent pour afficher les boutons d'authentification dans l'interface interactive. Les outils de génération de code client (openapi-generator) génèrent du code d'authentification automatiquement. Les outils de validation (express-openapi-validator, connexion pour Python) peuvent enforcer la sécurité à l'exécution en rejetant les requêtes non authentifiées sur les endpoints sécurisés. 42Crunch est un exemple d'outil qui analyse les spécifications OpenAPI pour identifier les problèmes de sécurité : endpoints sans sécurité définie, scopes trop larges, absence de limites de taille, validations manquantes. Ces analyses peuvent être intégrées dans les pipelines CI pour valider la sécurité des spécifications OpenAPI avant leur déploiement. La spécification OpenAPI peut être générée depuis le code (code-first approach avec annotations) ou écrite manuellement avant le code (design-first approach). Dans les deux cas, elle doit être traitée comme un artefact de sécurité auquel s'appliquent revue de code, versioning, et governance.