WAF cloud : comparer AWS WAF, Azure Front Door WAF et Google Cloud Armor en 2026

Les Web Application Firewalls (WAF) cloud sont devenus un composant essentiel de toute architecture web exposée sur Internet. Attaques SQLi, XSS, SSRF, bots malveillants, DDoS applicatifs : les WAF cloud offrent une protection en temps réel sans impact sur les performances, intégrée nativement aux services des hyperscalers. Ce guide compare AWS WAF, Azure Front Door WAF et Google Cloud Armor pour vous aider à choisir et configurer la solution adaptée.

Qu'est-ce qu'un WAF cloud et pourquoi en avoir un ?

Un WAF (Web Application Firewall) analyse le trafic HTTP/HTTPS entrant et bloque les requêtes malveillantes avant qu'elles n'atteignent vos applications. Contrairement aux firewalls réseau traditionnels (qui opèrent aux couches 3 et 4), un WAF opère à la couche 7 (applicative) et comprend le protocole HTTP.

Les WAF cloud sont gérés par les hyperscalers : pas d'infrastructure à maintenir, mise à l'échelle automatique, mises à jour des règles contre les nouvelles menaces. Ils s'intègrent nativement avec les autres services cloud (CloudFront/API Gateway pour AWS, Front Door pour Azure, Load Balancer pour GCP).

Ce qu'un WAF bloque

• Injections SQL (SQLi) : tentatives d'exfiltration ou de modification de la base de données
• Cross-Site Scripting (XSS) : injection de scripts malveillants
• Remote Code Execution (RCE) : Log4Shell (CVE-2021-44228), Spring4Shell
• Server-Side Request Forgery (SSRF) : accès au metadata endpoint du cloud provider
• Path traversal : tentatives d'accès aux fichiers système (../../etc/passwd)
• Bots malveillants : scrapers, credential stuffing, card testing
• Attaques DDoS de couche 7 : flood HTTP, slow HTTP attacks

AWS WAF v2

AWS WAF est le WAF natif d'Amazon Web Services. Il s'intègre avec CloudFront (CDN), Application Load Balancer (ALB), API Gateway et AppSync. Il est facturé à la Web ACL (5 $/mois) + par règle (1 $/mois) + par million de requêtes (0,60 $).

Managed Rule Groups AWS

AWS propose des groupes de règles gérées prêts à l'emploi :

• AWSManagedRulesCommonRuleSet : Règles génériques OWASP (SQLi, XSS, LFI, RFI). Le socle à activer sur tout environnement.
• AWSManagedRulesKnownBadInputsRuleSet : Bloque Log4JRCE, Windows Shellcode, Java deserialization attacks.
• AWSManagedRulesSQLiRuleSet : Protection SQL injection avancée en complément du Common Rule Set.
• AWSManagedRulesLinuxRuleSet : Protection contre les attaques spécifiques Linux (path traversal, command injection).
• AWSManagedRulesBotControlRuleSet : Détection et blocage des bots (scrapers, good bots vs bad bots). Facturation supplémentaire (10 $/mois + 1 $/million).
• AWSManagedRulesATPRuleSet : Account Takeover Prevention — protège les endpoints de login contre le credential stuffing. Requiert la configuration de l'URL de login.

Règles personnalisées AWS WAF

Au-delà des managed rules, AWS WAF permet des règles personnalisées via les Web ACL :

• Rate-based rules : Bloquer les IP dépassant X requêtes par 5 minutes. Essentiel contre le brute force et les floods HTTP.
• IP set rules : Blacklister ou whitelister des IP/plages CIDR. Intégration avec des threat intelligence feeds via Lambda + DynamoDB.
• Geo-match conditions : Bloquer le trafic de pays entiers. Utile pour les applications qui ne servent que la France ou l'Europe.
• String match : Bloquer des User-Agents, headers ou body patterns spécifiques.
• Labels : Système de tagging pour créer des règles composées (si label A et label B → BLOCK).

AWS WAF en mode Count vs Block

Toujours déployer les nouvelles règles en mode Count (journalisation sans blocage) pendant 1-2 semaines pour mesurer les faux positifs avant de passer en Block. Les managed rules d'AWS peuvent bloquer du trafic légitime sur des applications avec des formats de requêtes non-standards.

Azure Front Door WAF (Azure Application Gateway WAF)

Azure propose deux WAF : le WAF intégré à Azure Front Door (CDN + WAF global) et le WAF sur Application Gateway (WAF régional). Pour une protection globale, Front Door WAF est recommandé.

Core Rule Set (CRS) OWASP sur Azure

Azure WAF est basé sur les règles OWASP Core Rule Set (CRS 3.2 ou CRS 4.0). C'est le même projet open-source que ModSecurity utilise. Les règles CRS couvrent les 10 catégories OWASP Top 10 et sont régulièrement mises à jour par la communauté.

• CRS 3.2 : Version stable, compatible avec la plupart des applications
• CRS 4.0 : Version avec de meilleures détections ML-enhanced, réduction des faux positifs, support paranoia level 1-4
• Règles exclusives Microsoft : Protection contre les CVE critiques récentes (Log4Shell, ProxyShell, PrintNightmare)

Bot Management Azure Front Door

Azure Front Door WAF inclut un Bot Management intégré qui classe les bots en 3 catégories :

• Verified bots : Googlebots, Bingbots, moteurs de recherche légitimes (autorisés)
• Bad bots : Scrapers connus, outils d'attaque (Nikto, SQLmap) — bloqués automatiquement
• Unknown bots : Bots non identifiés — à configurer selon votre contexte (logger ou bloquer)

Politiques WAF Azure en Custom Rules

• Rate limiting basé sur l'IP (5 min window)
• Geo-filtering : bloquer les requêtes hors Europe pour les applications B2B françaises
• IP restriction par liste blanche pour les endpoints d'administration
• Header matching : vérifier la présence d'un token d'authentification pour certains endpoints

Google Cloud Armor

Google Cloud Armor est le WAF et anti-DDoS natif de Google Cloud Platform (GCP). Il s'intègre avec les Cloud Load Balancers (HTTP(S) LB, External LB) et protège aussi bien les services GKE que les applications sur Compute Engine ou Cloud Run.

Préconfigured WAF rules

Google Cloud Armor propose des règles préconfigurées basées sur les signatures OWASP CRS :

• sqli-stable / sqli-canary : Protection SQL injection (stable = production-tested, canary = nouvelles règles en bêta)
• xss-stable : Protection Cross-Site Scripting
• lfi-stable : Local File Inclusion
• rfi-stable : Remote File Inclusion
• rce-stable : Remote Code Execution (Log4Shell, CVE-2022-22965)
• scanner-detection : Bloquer les scanners automatiques (Nmap, Nikto)
• json-sqli-stable : SQLi dans les body JSON (APIs)

Adaptive Protection (ML)

L'Adaptive Protection de Cloud Armor utilise le machine learning pour détecter et atténuer automatiquement les attaques DDoS de couche 7. Il génère des règles WAF suggérées en temps réel pendant une attaque et peut bloquer automatiquement le trafic malveillant sans intervention humaine.

Google Cloud Armor et Kubernetes (GKE)

Pour les clusters GKE, Cloud Armor s'intègre via le Kubernetes Ingress Controller avec une annotation BackendConfig. Toutes les requêtes vers les Services GKE passent par le Load Balancer + Cloud Armor avant d'atteindre les pods.

Comparatif : AWS WAF vs Azure Front Door WAF vs Google Cloud Armor

• Protection OWASP : Les 3 offrent une couverture équivalente (managed rules / CRS). AWS et GCP maintiennent des règles maison pour les CVE critiques récentes. Azure s'appuie plus sur le CRS standard.
• Bot Management : AWS Bot Control et Azure Bot Management sont les plus avancés. GCP Cloud Armor est moins mature sur cette fonctionnalité.
• DDoS L7 : GCP Adaptive Protection est le plus innovant avec le ML. AWS Shield Advanced + WAF est efficace mais plus coûteux. Azure DDoS Protection + Front Door WAF est comparable.
• Coût : AWS WAF est le moins cher pour les petits volumes. Azure Front Door WAF est inclus dans certaines formules Front Door. GCP Cloud Armor Standard est gratuit (Cloud Armor Managed Protection Plus est payant).
• Intégration CI/CD : Les 3 supportent Terraform, Pulumi, et les IaC standards. AWS a l'avantage avec le plus grand écosystème de modules Terraform.
• False positive tuning : Azure CRS offre le paranoia level (1-4) pour ajuster le niveau de sensibilité. AWS WAF offre le mode Count pour tester. GCP permet les exceptions de règles par path.

Intégration WAF dans le pipeline CI/CD

Un WAF efficace doit évoluer avec votre application. Les pratiques DevSecOps recommandées :

• WAF-as-Code : Gérer les règles WAF via Terraform (aws_wafv2_web_acl, azurerm_web_application_firewall_policy, google_compute_security_policy). Versionner dans Git.
• Tests de régression WAF : Exécuter des tests DAST (OWASP ZAP, Nuclei) en staging pour vérifier que le WAF bloque les attaques sans bloquer les fonctionnalités.
• False positive monitoring : Connecter les logs WAF (CloudWatch, Azure Monitor, Cloud Logging) à votre SIEM pour détecter les faux positifs.
• Rotation des règles : S'abonner aux bulletins sécurité des hyperscalers pour activer rapidement les règles contre les nouvelles CVE critiques (Log4Shell a vu des règles AWS WAF publiées en heures).

Conformité NIS2 : le WAF cloud comme mesure technique

L'article 21 de NIS2 impose des mesures de sécurité appropriées. Un WAF cloud contribue à plusieurs exigences :

• Art. 21.2a (gestion des risques) : Le WAF réduit le risque d'exploitation des vulnérabilités applicatives OWASP
• Art. 21.2b (incidents) : Les logs WAF constituent une source de détection d'attaques. Les alertes WAF doivent alimenter votre processus de gestion des incidents.
• Art. 21.2h (supply chain) : Si vous exposez des API à des partenaires, le WAF protège aussi les API de vos consommateurs tiers
• Art. 21.2i (chiffrement) : Le WAF termine le TLS — vérifier que TLS 1.3 est actif et que les cipher suites obsolètes (TLS 1.0/1.1, RC4) sont désactivées