Un pare-feu réseau filtre des paquets ; un WAF lit des requêtes applicatives — il comprend le HTTP et voit l'injection SQL cachée dans un paramètre que tout le reste de votre stack laisse passer. Devenu quasi obligatoire (PCI-DSS v4 l'exige depuis mars 2025), il reste l'équipement le plus mal exploité du marché : déployé, jamais tuné, souvent en mode détection inutile. Ce guide couvre les deux faces — la gouvernance et la technique.
Chaque couche attrape ce que la précédente laisse passer. Le firewall voit un flux légitime vers le port 443 ; le WAF, lui, lit la requête et voit l'injection SQL cachée dans un paramètre. Il ne remplace ni le code sécurisé, ni l'anti-DDoS volumétrique.
Sous le capot, un WAF est un reverse proxy intelligent : il termine la connexion TLS, normalise et parse la requête, l'évalue contre un moteur de décision, puis transmet à l'origine — ou bloque.
L'étape critique est la normalisation : elle défait les encodages (URL, unicode, double-encoding) que les attaquants utilisent pour camoufler leurs payloads. Et sans déchiffrement TLS au niveau du WAF (étape 1), il ne voit qu'un flux opaque — inutile.
Tout WAF repose sur l'un de ces deux paradigmes, ou les deux. Les comprendre, c'est comprendre d'où viennent les faux positifs et les contournements.
Les WAF sérieux sont hybrides : signatures (négatif) + apprentissage du modèle applicatif (positif) + scoring d'anomalie. C'est l'approche de l'OWASP Core Rule Set.
Le jeu de règles de référence, l'OWASP Core Rule Set (CRS v4), ne bloque pas règle par règle : chaque règle qui déclenche ajoute un score d'anomalie, et la requête n'est bloquée que si le cumul dépasse un seuil. L'agressivité se règle via les paranoia levels (PL1 à PL4) : PL1 attrape les attaques évidentes avec très peu de faux positifs, PL4 attrape presque tout mais exige un tuning lourd.
En on-premise, le WAF se place en frontal applicatif dans la DMZ, derrière le firewall périmétrique, avec le TLS terminé à son niveau et l'IP source du client préservée via X-Forwarded-For. Le mode out-of-band (C) ne bloque rien : détection seule.
Le WAF n'est plus optionnel pour beaucoup d'organisations :
| Cadre | Exigence | Implication |
|---|---|---|
| PCI-DSS v4 | 6.4.1 / 6.4.2 — solution automatisée détectant et bloquant les attaques web | WAF obligatoire devant les apps traitant des données carte (depuis 03/2025) |
| NIS2 | Art. 21 — mesures de gestion des risques proportionnées | Mesure technique attendue pour les services web exposés |
| DORA | Protection & détection ICT (secteur financier) | Brique de protection applicative + journalisation |
| ISO 27001 | Annexe A — filtrage, protection réseau, surveillance | Contrôle à documenter dans le SoA |
Attention : pour un auditeur sérieux, « j'ai un WAF » ne suffit pas. La solution doit être en mode blocage actif, maintenue (règles à jour, exceptions gérées) et journalisée vers votre supervision. Et la cause n°1 d'échec n'est pas technique : c'est l'absence de propriétaire. Le WAF vit entre la sécurité (politique, validation), les ops (exploitation) et les devs (tuning des faux positifs sur leurs apps). Sans rôle défini pour chacun, les faux positifs s'accumulent jusqu'au jour où quelqu'un le passe en bypass « temporaire » — définitivement.
Pilotez-le avec quatre indicateurs : taux de faux positifs (requêtes légitimes bloquées), couverture (part des apps exposées réellement protégées), part du trafic en mode blocage vs détection seule, et délai de correction d'une règle après détection d'un faux positif.
Trois familles, trois philosophies. Le bon choix dépend moins de la marque que de votre modèle opérationnel : combien d'heures par semaine pouvez-vous réellement consacrer au tuning ?
| Solution | Type | Effort interne | Profil idéal |
|---|---|---|---|
| Cloudflare | Cloud / edge | Faible | Web public, scaling, équipe sécu réduite |
| Akamai | Cloud / edge | Faible | Grands comptes, fort trafic mondial |
| Imperva | Cloud + hybride | Moyen | Besoins avancés, mix cloud / on-premise |
| AWS WAF / Azure WAF | Cloud natif | Moyen | Workloads déjà chez l'hyperscaler |
| F5 Advanced WAF | Appliance | Élevé | Datacenter, exigences perf et contrôle fortes |
| Fortinet FortiWeb | Appliance / VM | Moyen | Parc Fortinet existant, bon rapport prix |
| ModSecurity + CRS | Open source | Élevé | Apache/Nginx, budget zéro, équipe technique |
| Coraza (OWASP) | Open source | Élevé | Le moteur moderne (Go), Caddy/Traefik, CRS v4 |
Côté open source : ModSecurity est passé sous la garde de la fondation OWASP début 2024 (fin du support commercial Trustwave mi-2024) — il reste utilisable, mais le moteur d'avenir est Coraza, écrit en Go et 100 % compatible CRS v4. Côté marché : sur le segment cloud, on ne parle plus de WAF seul mais de WAAP (WAF + anti-DDoS + bot management + protection API dans une plateforme unifiée), où Cloudflare, Akamai et Imperva sont régulièrement positionnés en leaders. Si vous lancez un projet aujourd'hui, raisonnez WAAP — mais un FortiWeb peut être le bon choix pour un parc Fortinet, et Coraza le bon choix pour un budget contraint avec de la compétence interne.
La règle qui sauve : jamais de bascule en blocage un vendredi soir, jamais de mode blocage direct sur une app critique sans phase d'observation. Un WAF mal tuné qui casse votre tunnel de paiement coûte plus cher que l'attaque qu'il devait bloquer. Cadrer le choix, le positionnement et la méthode de déploiement, c'est typiquement ce que j'accompagne.
La donnée est gratuite. Pour un avis sur l'impact réel sur votre parc et un plan de remédiation, on en parle.
Nous contacter →