Sécurité des API cloud : OWASP API Top 10 et bonnes pratiques AWS, Azure, GCP

Les API sont le système nerveux des architectures cloud modernes. Chaque microservice, chaque intégration SaaS, chaque application mobile communique via des API REST ou GraphQL. Et les attaquants le savent : selon l'OWASP, les vulnérabilités API représentent aujourd'hui le vecteur d'attaque le plus exploité dans les environnements cloud. Ce guide vous donne les bases pour sécuriser vos API dans AWS, Azure et GCP.

OWASP API Security Top 10 2023 : les vulnérabilités à connaître

L'OWASP a publié en 2023 sa liste des 10 risques de sécurité API les plus critiques. Pour les architectures cloud, ces vulnérabilités ont des implications spécifiques.

API1:2023 — Broken Object Level Authorization (BOLA)

La vulnérabilité la plus répandue et la plus impactante. Un endpoint comme GET /api/orders/{orderId} renvoie des données sans vérifier que l'utilisateur authentifié est bien propriétaire de cette commande. Un attaquant incrémente orderId et accède aux commandes de tous les autres utilisateurs.

Dans le cloud : Cette vulnérabilité est particulièrement dangereuse avec les Serverless (Lambda, Azure Functions, Cloud Functions) car chaque fonction tend à être développée indépendamment, sans framework d'autorisation cohérent. Solution : Vérifiez systématiquement dans chaque endpoint que l'objet demandé appartient à l'utilisateur connecté. Ne faites jamais confiance au paramètre d'URL seul.

API2:2023 — Broken Authentication

Mécanismes d'authentification défaillants : tokens JWT mal vérifiés (algorithme "none", secret faible), sessions sans expiration, endpoints d'authentification sans rate limiting (brute force), tokens stockés côté client sans protection.

Dans le cloud : Utilisez les services d'identité managés (AWS Cognito, Azure AD B2C, Google Identity Platform) plutôt que d'implémenter votre propre authentification. Configurez une durée d'expiration courte des tokens (15 min pour les access tokens, refresh token rotatif). Activez le rate limiting sur les endpoints d'authentification via API Gateway.

API3:2023 — Broken Object Property Level Authorization

L'API renvoie ou accepte plus de propriétés que nécessaire. Exemple : GET /api/users/{id} renvoie l'objet complet incluant le hash du mot de passe ou le numéro de carte bancaire. Ou : PUT /api/users/{id} accepte une propriété isAdmin: true dans le corps.

Solution : Implémentez des DTOs (Data Transfer Objects) stricts en entrée et en sortie. Ne sérialisez jamais directement vos objets de base de données. Utilisez des bibliothèques de validation (Joi, Zod, Pydantic) avec des schémas explicites pour chaque endpoint.

API5:2023 — Broken Function Level Authorization (BFLA)

Des endpoints d'administration (DELETE /api/users/bulk, GET /api/admin/logs) sont accessibles par des utilisateurs non administrateurs. Souvent lié à une confiance dans l'obscurité ("l'interface utilisateur n'affiche pas ce bouton, donc c'est sécurisé").

Dans le cloud : Chaque route d'API doit avoir une vérification d'autorisation explicite basée sur des rôles (RBAC) ou des permissions. Utilisez des middlewares d'autorisation centralisés. Dans AWS API Gateway, configurez des Authorizers Lambda pour chaque route sensible.

Sécuriser les API avec les services cloud natifs

AWS API Gateway

AWS API Gateway offre plusieurs mécanismes de sécurité natifs à activer :

• Authorizer Lambda : Fonction Lambda qui valide chaque token JWT avant de router la requête vers le backend. Permet une logique d'autorisation centralisée et réutilisable
• Cognito User Pools Authorizer : Validation automatique des tokens JWT Cognito sans code supplémentaire
• WAF (Web Application Firewall) : Règles de filtrage OWASP, rate limiting par IP, protection contre les injections SQL et XSS
• Throttling : Rate limiting par clé API ou par endpoint (évite les attaques DDoS et le brute force)
• Mutual TLS (mTLS) : Pour les API B2B, impose aux clients de présenter un certificat client valide
• Resource Policies : Restrictions d'accès par VPC, par IP source, par compte AWS

Azure API Management (APIM)

APIM est la solution de gateway API d'Azure, avec des fonctionnalités de sécurité intégrées :

• Politiques d'authentification : Validation JWT, clés d'abonnement (Ocp-Apim-Subscription-Key), OAuth2 avec Azure AD
• Rate limiting par politiques : rate-limit-by-key et quota-by-key pour limiter les appels par client
• Azure Defender for APIs : Détection des anomalies comportementales sur les APIs (appels inhabituels, tentatives d'exploration)
• IP filtering : Listes blanches/noires d'adresses IP en entrée

GCP Cloud Endpoints / Apigee

Google propose deux solutions API gateway selon la complexité : Cloud Endpoints (plus simple, intégré à GKE) et Apigee (enterprise, avec analytics avancés). Les deux supportent la validation OpenAPI, l'authentification Google Identity et le rate limiting.

Authentification OAuth2 et OIDC : bonnes pratiques cloud

OAuth2/OIDC sont les standards d'authentification API en environnement cloud. Les erreurs de configuration les plus fréquentes :

• Clés JWT avec algorithme "none" ou HS256 avec secret faible : Utilisez RS256 (asymétrique) avec des clés de 2048 bits minimum. Validez toujours l'algorithme côté serveur.
• Durée de vie trop longue des access tokens : 15 minutes pour les access tokens, 30 jours pour les refresh tokens. Implémentez la rotation des refresh tokens (un refresh token ne s'utilise qu'une seule fois).
• Manque de validation des claims : Vérifiez toujours iss (émetteur), aud (audience), exp (expiration) et sub (sujet) côté serveur.
• Tokens stockés en localStorage : Utilisez httpOnly cookies pour les tokens côté navigateur. Le localStorage est accessible par JavaScript et donc vulnérable aux attaques XSS.

Monitoring et détection des attaques API

Un SOC API doit surveiller les signaux suivants :

• Exploration de ressources : Un utilisateur qui incrémente des IDs (orderId=1, 2, 3, …) cherche probablement des vulnérabilités BOLA
• Volume d'appels anormal : Un client qui appelle 1 000 fois par minute un endpoint d'authentification fait du brute force
• Erreurs 4xx massives : Beaucoup d'erreurs 403 ou 404 sur des endpoints inhabituels indiquent une phase de reconnaissance
• Taux d'erreur sur des endpoints spécifiques : Des pics d'erreurs sur un endpoint précis peuvent indiquer un test de vulnérabilité

Les outils de monitoring API cloud : AWS X-Ray + CloudWatch Logs Insights, Azure Monitor + Application Insights, Datadog APM, Elastic APM. Pour la détection des attaques spécifiques aux API, des solutions spécialisées comme Salt Security, Noname Security ou Traceable AI sont disponibles.

Tests de sécurité des API : DAST et fuzzing

Intégrez les tests de sécurité API dans votre pipeline CI/CD :

• OWASP ZAP : Scanner automatique open source, intégrable dans GitHub Actions ou GitLab CI. Teste automatiquement les vulnérabilités OWASP API Top 10 sur votre spec OpenAPI
• Burp Suite : Solution professionnelle pour les pentests manuels et semi-automatiques des API
• RESTler : Outil de fuzzing intelligent de Microsoft Research, génère automatiquement des séquences d'appels API valides et cherche des comportements inattendus
• Postman + Newman : Automatisez vos tests de sécurité fonctionnels (collections Postman exécutées dans CI avec Newman)