Pare-feu applicatif web (WAF)
Un pare-feu applicatif web, ou WAF, filtre les requêtes HTTP adressées à un site et rejette celles qui correspondent à une attaque connue.
Définition
Un pare-feu applicatif web, ou WAF, filtre les requêtes HTTP adressées à un site et rejette celles qui correspondent à une attaque connue. L’OWASP le décrit comme un pare-feu applicatif pour les applications HTTP, qui applique un jeu de règles à une conversation HTTP. Il lit le contenu de la requête, là où un pare-feu réseau ne voit que des adresses et des ports.
Qu’est-ce qu’un pare-feu applicatif web ?
Un filtre placé devant le site, qui lit chaque requête avant de la laisser passer.
La définition de l’OWASP tient en une phrase : c’est un pare-feu applicatif pour les applications HTTP, qui applique un jeu de règles à une conversation HTTP. La nuance compte. Un pare-feu réseau décide d’après l’origine et le port : cette machine peut parler à ce service, celle-là non. Un WAF, lui, ouvre l’enveloppe. Il regarde l’adresse demandée, les paramètres, les en-têtes, le corps de la requête, et cherche des formes connues d’attaque.
L’OWASP précise aussi qu’il se présente sous plusieurs formes, boîtier, module de serveur ou filtre, et qu’il se personnalise pour une application donnée. Cette personnalisation a un coût : elle se maintient à mesure que l’application évolue. Un WAF n’est pas un objet qu’on pose une fois. Posé après coup sur un site déjà infecté, il masque le symptôme sans retirer le code : le nettoyage vient d’abord.
Devant le site, ou dedans
La position détermine ce que le refus coûte en ressources.
Un WAF d’hébergement s’exécute au niveau du serveur web. Il répond avant que PHP ne démarre, avant que WordPress ne se charge, avant la moindre requête en base. Une extension de sécurité, elle, s’exécute à l’intérieur de WordPress : pour refuser une requête, le site a déjà démarré, chargé ses extensions et construit une page. Les deux refusent, mais l’un refuse gratuitement et l’autre facturé.
| Critère | WAF d’hébergement | Extension de sécurité |
|---|---|---|
| Moment du refus | Avant le démarrage de PHP | Après le chargement de WordPress |
| Coût d’un refus | Quelques octets | Une page complète |
| Réglage | Chez l’hébergeur, peu accessible | Dans le tableau de bord |
| Connaissance de WordPress | Générique | Fine, comptes et rôles compris |
| Survit à une panne du site | Oui | Non |
Les deux se complètent plus qu’ils ne se remplacent. Le filtre d’hébergement encaisse le bruit de fond, qui représente l’essentiel du volume. L’extension traite ce qui demande de connaître WordPress : les tentatives sur la page de connexion, l’énumération des comptes, les appels à XML-RPC.
Quelles attaques un pare-feu applicatif arrête
Celles qui se reconnaissent à la forme de la requête, pas à l’intention.
Trois familles composent l’essentiel du trafic filtré. L’injection SQL glisse un fragment de requête de base de données dans un champ ou un paramètre d’adresse, pour faire lire ou modifier ce qui ne devrait pas l’être. Le cross-site scripting, abrégé XSS, insère du script dans une page afin qu’il s’exécute chez le visiteur suivant. La traversée de répertoire, enfin, demande un fichier situé en dehors du site, un fichier de configuration le plus souvent. Ces trois formes laissent des traces caractéristiques dans l’URL ou dans le corps de la requête, et c’est précisément ce qu’une règle sait reconnaître.
Le jeu de règles de référence est publié par l’OWASP, sous le nom de Core Rule Set, et sert de socle à la plupart des filtres du marché. Une confusion mérite d’être levée au passage : une attaque par déni de service distribué ne relève pas de cette couche. Elle noie le service sous le volume, sans forme particulière à reconnaître, et se traite en amont, au niveau du réseau.
Ce qu’un WAF n’arrête pas
Tout ce qui passe par une porte légitime avec des identifiants valides.
Un mot de passe deviné ouvre une session normale : rien à filtrer. Une extension abandonnée dont la faille est publiquement documentée s’exploite parfois par une requête qui ressemble à une requête ordinaire. Un compte administrateur créé par un attaquant après une intrusion, une porte dérobée déposée dans un fichier de thème, un code malveillant déjà installé : le filtre regarde ce qui entre, pas ce qui vit à l’intérieur.
Un WAF n’est pas un substitut aux mises à jour. C’est la confusion la plus coûteuse. Il fait gagner du temps entre la publication d’une faille et l’application du correctif, ce qui est précieux. Il ne dispense pas d’appliquer le correctif, et un site protégé mais jamais mis à jour finit par être atteint par ce que les règles génériques ne couvrent pas.
Ce que cela donne sur un site réel
Mesure du 8 septembre 2026, sur quatorze heures de journaux d’un site vitrine WordPress. Deux traitements coexistent, et le journal les sépare nettement. 765 requêtes reçoivent un refus qui pèse exactement 36 octets, toujours le même poids, et proviennent presque toutes de trois machines d’un même fournisseur de cloud. Dans la même fenêtre, 899 pages introuvables rendues par WordPress pèsent 5 857 octets, soit 163 fois plus. Le contrôle en direct confirme le mécanisme, sur trois passes espacées, chacune doublée d’une adresse témoin qu’on ne touche pas : une demande du fichier de configuration .env reçoit un refus en 41 à 64 millisecondes, quand l’adresse témoin reçoit une page introuvable de WordPress en 240 à 280 millisecondes. Quatre à six fois plus vite, pour huit fois moins d’octets. Une précaution de lecture s’impose : les octets du journal sont ceux réellement transmis, donc compressés pour les clients qui l’acceptent, alors qu’un appel en ligne de commande reçoit la page entière. On ne compare que ce qui se mesure de la même façon, les volumes du journal entre eux, les temps mesurés en direct entre eux.
Questions fréquentes
Une extension de sécurité suffit-elle, sans WAF d’hébergement ?
Elle protège, mais elle fait travailler le site pour chaque refus. Sur un hébergement mutualisé, ce coût se paie en lenteur aux heures de forte reconnaissance automatisée. Le filtre en amont est ce qui rend le refus indolore.
Un WAF peut-il bloquer des visiteurs légitimes ?
Oui, et c’est son principal effet indésirable. Un formulaire qui accepte du texte long, un éditeur qui colle du code, une intégration qui envoie des données inhabituelles : ces cas ressemblent à des attaques pour une règle générique. Un WAF se règle, il ne s’installe pas.
Comment savoir si mon hébergement en a un ?
En demandant une adresse manifestement sensible, comme un fichier de configuration, et en regardant la réponse. Un refus très rapide et très léger indique un filtre en amont. Une page complète rendue par WordPress indique le contraire.
Un WAF protège-t-il un site déjà infecté ?
Non. Il filtre ce qui entre, pas ce qui est déjà présent. Un site compromis se traite par un nettoyage et une remise à niveau, le filtre servant ensuite à éviter la récidive par la même voie.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.