WAF (web application firewall) : ce qu'il bloque, ce qu'un
pentester contourne

On envoie une requête un peu tordue, un paramètre qui contient une apostrophe et un OR 1=1, et la réponse revient : 403 Forbidden, page de blocage générique, un identifiant de "ray" ou d'incident dans un coin. On n'a rien appris. Ce 403 ne dit pas si l'application était vulnérable : il dit qu'un équipement placé devant elle a reconnu un motif dans la chaîne HTTP et a coupé avant que le code applicatif ne voie quoi que ce soit. Ce gardien, c'est un WAF.

Un WAF (web application firewall, pare-feu applicatif) rend de vrais services, et on le vend régulièrement pour une garantie qu'il ne donne pas : celle que l'application derrière lui est sûre. Entre les deux, il y a un moteur de règles, des seuils réglables, des angles morts assumés par les éditeurs eux-mêmes, et tout un catalogue de contournements publics dont un pentest se sert pour mesurer la surface d'attaque qui subsiste, WAF ou pas WAF.

Le WAF, une couche 7 posée devant l'application

Un pare-feu réseau classique travaille aux couches 3 et 4 du modèle OSI : il raisonne en adresses IP et en ports, il ne lit pas ce qui transite. Un WAF vit une couche plus haut, à la couche 7, la couche applicative. Il termine (ou observe) la connexion HTTP, décortique l'URL, la chaîne de requête, les en-têtes, les cookies et le corps, puis décide de laisser passer, de journaliser, de challenger ou de bloquer. Un intermédiaire qui lit le protocole, donc, et qui prend ses décisions sur ce qu'il y lit.

On le rencontre sous trois formes, et la forme change ce qu'on peut en attendre. En reverse proxy cloud, le trafic passe par l'infrastructure d'un fournisseur avant d'atteindre votre serveur (Cloudflare, AWS WAF devant CloudFront, Akamai, Imperva). En appliance ou module, le WAF tourne sur votre propre infrastructure, devant ou dans le serveur web (F5 BIG-IP, NGINX App Protect, le module ModSecurity pour Apache, nginx ou IIS). En bibliothèque embarquée enfin, comme Coraza, le moteur de règles s'intègre directement dans le proxy (Caddy, Envoy) sans boîte dédiée.

Comment un WAF décide de bloquer

Deux familles de détection cohabitent, souvent dans le même produit. La première est la règle de signature : on compare la requête à un catalogue de motifs d'attaque. Le catalogue de référence en open source est l' OWASP Core Rule Set (CRS), un jeu de règles générique utilisé par ModSecurity, Coraza et dérivé chez plusieurs éditeurs cloud. Sa version 4 la plus récente est la v4.29.0, publiée le 17 août 2026. Pour l'injection SQL, par exemple, la règle 942100 ne se contente pas d'une expression régulière : elle appelle l'opérateur @detectSQLi, c'est-à-dire la bibliothèque d'analyse lexicale libinjection.

La seconde famille est le scoring d'anomalie. Plutôt que de bloquer dès la première règle, le CRS additionne des points : une règle de sévérité critique vaut 5 points, une erreur 4, un avertissement 3, une notice 2. Quand le total franchit le seuil entrant par défaut, fixé à 5, la règle d'évaluation 949110 déclenche le blocage avec le message "Inbound Anomaly Score Exceeded". L'agressivité se règle par le niveau de paranoïa (paranoia level, PL), de PL1 à PL4. Le PL1, celui par défaut, vise le minimum de faux positifs. Le PL4 active des règles très strictes que la documentation du CRS décrit elle-même comme générant "un grand nombre de faux positifs", à utiliser à ses risques.

Les WAF cloud ajoutent leurs propres briques par-dessus. Le jeu OWASP de Cloudflare reprend le CRS (dérivé de la 3.3.0) avec ses PL1 à PL4 et trois seuils de score prêts à l'emploi : bas à 60 et plus, moyen à 40 et plus (le défaut), haut à 25 et plus. AWS WAF, F5, Akamai ou Imperva y greffent du fingerprinting TLS (JA3, JA4), de la réputation d'IP et des modèles comportementaux de détection de bots. Utile contre l'automatisation, sans rien changer au point aveugle de fond : aucun de ces moteurs ne sait ce que votre application fera de la donnée une fois qu'elle sera passée.

Une note d'histoire, parce qu'elle éclaire l'écosystème : ModSecurity, le moteur open source historique né comme module Apache en 2002, a changé de gardien. Trustwave en a transféré la garde à la fondation OWASP en janvier 2024 ; il reste sous licence Apache 2.0, en version 3.0.16 pour la branche v3, publiée en juin 2026. Coraza en est la réécriture en Go, annoncée "100 % compatible avec l'OWASP Core Rule Set v4" et déployable dans Caddy ou Envoy. C'est le socle libre sur lequel s'appuient beaucoup de déploiements maison.

Ce qu'un WAF bloque, et ce qu'il ne bloquera jamais

Le WAF est excellent sur un registre précis, et il faut le lui reconnaître. Il absorbe le bruit de fond d'Internet : les scanners automatisés qui rejouent des exploits connus, les tentatives de masse contre une CVE fraîche, les bots qui ratissent les /wp-login.php et les /.env. Il gagne du temps quand une vulnérabilité connue est publiée et que le correctif n'est pas encore déployé, en bloquant le motif d'exploitation le temps de patcher. Il complique la vie d'un attaquant pressé. Ce sont de vrais services, et ils justifient sa présence.

Le problème commence quand on lui prête des pouvoirs qu'il n'a pas. Un WAF raisonne sur une chaîne HTTP ; la faille, elle, vit dans la logique de l'application. Toute une famille de vulnérabilités ne ressemble à aucun motif d'attaque parce qu'elle utilise des requêtes parfaitement légitimes en apparence.

• Les failles d'autorisation et l'IDOR : changer /facture/1042 en /facture/1043 est une requête HTTP normale. Aucune signature ne s'y déclenche, et pourtant vous lisez la facture du voisin. C'est le risque n°1 de l' OWASP Top 10 2025, le Broken Access Control, et il est structurellement invisible au filtrage.
• La logique métier : un panier à quantité négative qui crédite le compte, un coupon cumulable à l'infini, un workflow qu'on saute d'une étape. Le WAF ne connaît pas vos règles de gestion, il ne peut pas les défendre.
• Les injections encodées ou fragmentées qui ne franchissent pas le seuil de score, ou qui atteignent l'application par un canal que le WAF n'inspecte pas complètement (corps volumineux, format non parsé).
• La faille en amont : un secret exposé dans un dépôt public, un identifiant réutilisé, un sous-domaine oublié. Rien de tout cela ne passe par le WAF, donc rien de tout cela n'est filtré.

Les contournements de WAF, techniques documentées

Ce qui suit est public, enseigné et défensif : comprendre comment un filtre se contourne, c'est comprendre pourquoi il ne remplace pas un correctif. Tout cela ne se pratique que dans un cadre autorisé, sur un périmètre mandaté ou un laboratoire que l'on possède.

Rejouer la charge sous une autre forme

Une signature cherche un motif ; on change le motif sans changer le sens. L'encodage est le levier le plus simple : URL-encoding, double encodage, encodage Unicode ou hexadécimal, casse mélangée, commentaires SQL insérés au milieu d'un mot-clé. La fragmentation répartit la charge : la pollution de paramètres HTTP (HPP, référence WSTG-INPV-04) envoie deux fois le même paramètre avec des valeurs différentes, en pariant sur un désaccord d'interprétation. ASP.NET sur IIS concatène les deux valeurs avec une virgule, PHP sur Apache ne garde que la dernière, Tomcat garde la première : si le WAF lit l'une et l'application l'autre, la charge passe.

Passer sous le radar de la taille inspectée

Un WAF n'inspecte pas un octet infini. AWS WAF, par exemple, documente ses limites : il lit au plus les 8 premiers Ko du corps derrière un ALB, et cette limite-là est fixe ; derrière CloudFront ou API Gateway, il lit 16 Ko par défaut, extensible à 64 Ko dans la configuration. Il inspecte par ailleurs au plus 8 Ko d'en-têtes ou 200 en-têtes. Au-delà, on choisit soit de continuer l'inspection sur la partie visible, soit de la sauter : une charge poussée après la limite, dans un corps volumineux, peut n'être jamais vue. Sur un contournement de ce genre, le pentester mesure exactement où la fenêtre d'inspection s'arrête.

Casser l'accord entre le frontal et l'origine

Le request smuggling (désynchronisation HTTP) exploite un désaccord entre le serveur frontal (souvent le WAF ou le CDN) et le serveur applicatif sur la frontière entre deux requêtes. En jouant sur les en-têtes Content-Length et Transfer-Encoding (les variantes CL.TE, TE.CL, TE.TE), on glisse une requête que le frontal ne compte pas et que l'origine exécute. James Kettle l'a remis au premier plan avec sa recherche "HTTP Desync Attacks", publiée en août 2019, avec cette formule qui résume l'enjeu : quand un système repose entièrement sur son frontal pour la sécurité, franchir ce frontal, c'est entrer sans obstacle.

Trouver l'origine et ignorer le WAF

La technique la plus radicale ne contourne pas le filtre : elle le court-circuite. Un WAF cloud protège tant que tout le trafic passe par lui. Si un attaquant trouve l'adresse IP réelle de l'origine derrière le CDN, il parle au serveur en direct et le WAF ne voit plus rien. Les fuites sont connues : l'historique DNS d'un domaine avant sa migration derrière le CDN, un enregistrement A de sous-domaine (direct., origin., staging.) qui pointe hors des plages du CDN, une entrée MX dont l'IP mail coïncide avec l'origine, ou un certificat en Certificate Transparency qui révèle un nom d'hôte oublié.

C'est exactement ce que traque le module de surveillance de surface d'attaque d'own2pwn, sous le finding cdn_origin_bypass : il compare les IP résolues aux plages connues de Cloudflare, CloudFront et Fastly, teste les sous-domaines et les MX, remonte ces fuites comme des indices, et ne qualifie une origine confirmée que si une connexion directe en 2xx, avec l'en-tête Host du domaine, renvoie le même titre de page que le domaine protégé. La parade côté défense est nommée par les fournisseurs : n'accepter sur l'origine que les plages d'IP du CDN, ou activer l' Authenticated Origin Pulls en mTLS pour que le serveur refuse tout ce qui ne vient pas du WAF. Ce point de durcissement rejoint la logique des en-têtes HTTP de sécurité et de la cartographie de l'exposition qu'étudie l' EASM, la gestion de surface d'attaque externe.

Faux positifs et le piège du mode journalisation seule

Un WAF trop strict casse le trafic légitime. Un formulaire qui accepte une apostrophe, un nom de famille avec un tiret, un champ libre où un développeur colle du code, une requête GraphQL touffue : tout cela peut ressembler à une attaque pour une règle de PL3 ou PL4. La réponse organisationnelle est presque toujours la même, et elle est mauvaise : on bascule le moteur en mode détection seule.

Ce mode a un nom technique. Dans ModSecurity, la directive SecRuleEngine accepte trois valeurs : On, Off, et DetectionOnly, qui "évalue les règles mais n'exécute jamais d'action perturbatrice". Chez Cloudflare, l'action Log, réservée aux plans Enterprise, est décrite comme "recommandée pour valider les règles avant de passer à une action plus sévère". Ces modes existent pour une bonne raison : régler la configuration sans couper les clients pendant la mise au point. Leur défaut tient à leur durée de vie. Une équipe passe en journalisation le temps de traiter un faux positif, l'incident s'éloigne, et personne n'ose rebasculer en blocage. Le WAF produit alors des journaux que personne ne lit, pour une protection nulle. J'ouvre souvent un rapport en le vérifiant : le WAF est là, il est en log only, et il y est resté.

Le WAF face à NIS2 et au ReCyF

Un WAF est une mesure de protection, et à ce titre il coche une case dans une démarche de conformité. La directive NIS2 attend à son article 21, paragraphe 2 des mesures couvrant "la sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités" (point e), et "des politiques et des procédures pour évaluer l'efficacité des mesures de gestion des risques en matière de cybersécurité" (point f). Un filtre applicatif participe du point (e). Le point (f), lui, réclame la démonstration que les mesures fonctionnent, et aucun équipement ne la produit sur lui-même.

Côté français, le référentiel de l'ANSSI qui traduit ces objectifs, le ReCyF (Référentiel Cyber France), présenté le 17 mars 2026, est diffusé en document de travail, l'Agence précisant qu'aucune version définitive n'est encore publiée tant que la transposition n'est pas achevée. La loi de transposition, dite loi Résilience, n'est d'ailleurs pas promulguée au moment de la rédaction (septembre 2026) : adoptée par le Sénat le 12 mars 2025, son rapport de commission à l'Assemblée nationale a été déposé le 10 septembre 2025, sans passage en séance publique à ce stade. Sur les seuils et le calendrier définitifs, tout reste donc au conditionnel.

Cette démonstration relève du test d'intrusion en entreprise, et le mener sur une application protégée par un WAF suppose une précaution qu'on oublie souvent : on teste deux fois.

Sans la première passe, un pentest "WAF actif" peut rendre un rapport vert alors que le code est troué : le WAF a masqué les failles le jour du test, il les masquera jusqu'au jour où quelqu'un trouve l'origine. C'est le sens de la distinction que traite l'article sur les attaques par injection SQL : un WAF rend deux vrais services, filtrer le bruit et tenir en attendant le correctif, mais la parade qui tient reste dans le code.

À retenir

• Un WAF filtre le HTTP à la couche 7 : il arrête le bruit de masse, les scanners et l'exploitation de CVE connues, en reverse proxy cloud, en appliance ou en module (ModSecurity, Coraza).
• Il détecte par signatures (OWASP CRS, opérateur @detectSQLi) et par scoring d'anomalie (seuil entrant par défaut à 5, niveaux de paranoïa PL1 à PL4). Plus le niveau monte, plus les faux positifs montent.
• Il ne voit pas la logique métier : IDOR, failles d'autorisation, workflows détournés et failles en amont passent au travers sans déclencher une règle.
• Les contournements sont documentés : encodages, pollution de paramètres HTTP (WSTG-INPV-04), dépassement de la taille inspectée, request smuggling, et surtout la découverte de l'IP d'origine derrière le CDN.
• Le mode journalisation seule est un réglage temporaire qui devient permanent : un WAF qu'on n'ose plus mettre en blocage ne protège plus rien.
• Pour NIS2 et le ReCyF, le WAF est une mesure de protection, pas une preuve d'efficacité : seul un pentest la fournit, et il se mène en deux passes, en liste blanche puis avec le WAF actif.

Devant un WAF en production, la question à poser n'est plus "est-il bien configuré" mais "que reste-t-il quand on l'enlève de l'équation". Ça se répond en conditions réelles, avec un pentest web blackbox qui teste votre application avec le filtre, puis en liste blanche, et qui vérifie au passage l'étanchéité de votre origine. Le WAF n'a plus alors à porter une promesse qu'il n'a jamais faite.

Questions fréquentes sur le WAF