WAF
WAF (Web Application Firewall) : pare-feu spécialisé qui inspecte le trafic HTTP/HTTPS avant qu'il n'atteigne l'application, bloque les requêtes malveillantes (injections SQL, XSS, path traversal) et protège contre les attaques applicatives courantes.
Un WAF (Web Application Firewall) est un pare-feu spécialisé qui inspecte le trafic HTTP/HTTPS à destination d'une application web et bloque les requêtes correspondant à des patterns d'attaque connus. Contrairement à un firewall réseau classique qui filtre des paquets IP selon leur source et leur destination, un WAF comprend le protocole HTTP : il lit les URL, les headers, les cookies, les paramètres GET et POST, et applique des règles pour détecter les tentatives d'injection SQL, de cross-site scripting, de path traversal, de command injection ou d'attaques sur la logique métier.
Définition technique
Comment fonctionne un WAF
Un WAF se place en coupure entre le client (navigateur ou bot) et le serveur applicatif. Chaque requête HTTP entrante est analysée en temps réel : ses composants sont décomposés (URL, méthode, headers, corps), normalisés (décodage URL, décodage base64, conversion d'encodage) et comparés à une liste de signatures ou de règles. Si la requête matche un pattern d'attaque connu, le WAF la bloque (retour 403 ou 404), la log, et éventuellement la transmet à un SIEM pour corrélation.
Les règles viennent typiquement de deux sources : des signatures fournies par l'éditeur du WAF (mises à jour régulièrement pour couvrir les nouvelles CVE), et des règles personnalisées écrites par l'équipe sécurité pour répondre aux spécificités de l'application (par exemple : bloquer toute requête vers /admin qui ne vient pas d'une IP d'entreprise).
Modes de déploiement
- WAF cloud managé (Cloudflare, AWS WAF, Akamai) — placé devant le site à l'échelle du CDN. Avantage : déployable en quelques minutes, mises à jour gérées par l'éditeur, protection DDoS intégrée. Inconvénient : le trafic transite par un tiers, les règles sont parfois opaques, le coût peut grimper avec le volume.
- WAF reverse proxy (ModSecurity sur Nginx ou Apache, Coraza sur Envoy) — déployé sur votre propre infrastructure, en amont du serveur applicatif. Avantage : contrôle total sur les règles, pas de tiers dans le chemin de requête, open source et gratuit. Inconvénient : demande de l'expertise pour configurer et maintenir, pas de protection DDoS intrinsèque.
- WAF applicatif (plugin WordPress type Wordfence, middleware PHP/Node) — intégré au code applicatif. Avantage : accès au contexte métier pour des règles précises. Inconvénient majeur : intervient après que le serveur ait déjà alloué des ressources à la requête, donc coûteux en performance et vulnérable aux attaques qui exploitent le chemin de chargement lui-même.
Enjeux actuels
Les faux positifs, ennemi du déploiement
Le principal défi pratique d'un WAF, c'est la gestion des faux positifs : des requêtes légitimes qui matchent accidentellement une règle de sécurité. Une URL contenant le mot "SELECT" peut être confondue avec une tentative d'injection SQL. Un commentaire d'utilisateur qui inclut du code HTML peut déclencher une alerte XSS. Sans phase de tuning, un WAF peut bloquer 20% du trafic légitime — ce qui le rend inutilisable en production.
La stratégie recommandée consiste à déployer le WAF en mode détection dans un premier temps (observation sans blocage), analyser les hits pendant plusieurs semaines, créer des exceptions pour chaque faux positif identifié, puis basculer en mode bloquant quand on a la preuve statistique que le bruit est maîtrisé.
Nano-WAF et filtrage léger en périphérie
À l'opposé des WAF managés complexes, il existe une approche "nano-WAF" : quelques centaines de lignes de code qui effectuent un filtrage périmètre basique (méthodes HTTP inhabituelles, User-Agents de scanners connus, chemins d'attaque classiques). Cette approche ne remplace pas un vrai WAF pour des attaques sophistiquées, mais elle ferme gratuitement les vecteurs les plus évidents et réduit considérablement le bruit dans les logs. C'est ce que j'expérimente dans mon article sur la sécurisation de WordPress sans plugins, où un mu-plugin léger combine allowlist d'User-Agents légitimes, blocklist de scanners et stealth 404.
Applications pratiques
La combinaison la plus efficace consiste à empiler plusieurs WAF à des niveaux différents : un WAF managé cloud (Cloudflare, AWS WAF) pour absorber le bruit massif et la protection DDoS, un reverse proxy avec ModSecurity ou un nano-WAF applicatif pour des règles spécifiques à l'application, et des validations applicatives pour les cas métier. Chaque couche complète les autres — c'est l'application classique de la Defense in Depth.
Questions fréquentes
Quelle différence entre un firewall classique et un WAF ?
Un firewall classique travaille aux couches 3-4 du modèle OSI : il filtre les paquets IP selon des règles d'adresses source/destination, de ports et de protocoles. Il ne lit pas le contenu des requêtes HTTP, il ne comprend pas ce qu'elles font. Un WAF travaille à la couche 7 (application) : il inspecte le contenu complet des requêtes HTTP — URL, headers, cookies, paramètres GET/POST, corps JSON — et applique des règles spécifiques aux attaques web. Il peut détecter une tentative d'injection SQL dans un champ de formulaire, un payload XSS dans un paramètre d'URL, ou une tentative de path traversal vers /etc/passwd.
Quels sont les WAF les plus utilisés ?
Côté cloud managé : Cloudflare WAF, AWS WAF, Akamai Kona, Azure Application Gateway WAF, Google Cloud Armor. Côté open source : ModSecurity (le standard de facto, désormais maintenu par OWASP sous le nom Coraza pour Go), avec les règles OWASP CRS (Core Rule Set) qui couvrent les attaques du Top 10 OWASP. Côté applicatif : certains frameworks et plugins WordPress (Wordfence, Sucuri) implémentent un mini-WAF côté PHP — avec tous les inconvénients d'un contrôle tardif.
Un WAF suffit-il à sécuriser une application ?
Non. Un WAF est une couche de défense, pas une solution complète. Il bloque des patterns connus mais peut être contourné par des attaques ciblées ou des vulnérabilités applicatives spécifiques. Un WAF mal configuré produit aussi beaucoup de faux positifs qui frustrent les utilisateurs légitimes. Il doit faire partie d'une stratégie de Defense in Depth : validation d'entrée côté application, requêtes préparées en base de données, authentification solide, chiffrement, et monitoring. Le WAF filtre le bruit, mais l'application reste responsable de sa propre sécurité.