Qu'est-ce qu'un pare-feu applicatif (WAF) ?
En bref
Un pare-feu applicatif est un filtre placé entre les visiteurs et votre site. Il analyse chaque requête et bloque celles qui correspondent à des tentatives connues, comme une injection ou l'accès à un fichier sensible. Il fait gagner du temps face aux attaques automatisées, mais il ne corrige aucune faille du code et demande un réglage pour éviter de bloquer des visiteurs légitimes.
Un pare-feu classique décide quels services du serveur sont joignables. Un pare-feu applicatif, souvent désigné par le sigle WAF, travaille un cran plus loin : il examine le contenu des requêtes adressées à votre site et écarte celles qui ressemblent à une tentative d'abus. Il s'intercale entre le visiteur et l'application, sans qu'il soit nécessaire de modifier cette dernière.
Ce qu'il filtre concrètement
- les requêtes portant les signatures d'attaques connues, notamment les tentatives d'injection dans les champs de saisie ;
- les demandes visant des fichiers qui ne devraient pas être publics, comme les fichiers de configuration ou les archives ;
- les outils automatisés qui parcourent le site à grande vitesse à la recherche d'une faille ;
- les séries d'essais de connexion, grâce à une limitation du nombre de requêtes par origine ;
- selon les produits, le trafic provenant de pays ou de réseaux où vous n'avez aucune activité.
Où il se place
| Emplacement | Principe | À savoir |
|---|---|---|
| Service en amont | Le trafic passe par un intermédiaire avant d'atteindre votre serveur, souvent couplé à un CDN. | Mise en place rapide, mais l'intermédiaire voit le trafic déchiffré : vérifiez où il est situé. |
| Sur le serveur | Un module installé devant l'application analyse les requêtes localement. | Les données ne sortent pas, la charge repose sur votre serveur. |
| Dans l'application | Une extension filtre les requêtes une fois arrivées. | Simple à activer, mais la requête a déjà atteint le site. |
Deux modes de fonctionnement
La plupart des produits proposent d'abord un mode observation, qui enregistre ce qui aurait été bloqué sans agir, puis un mode blocage. Passer directement au blocage expose à interrompre des usages légitimes : un formulaire d'édition de contenu contenant du code, une API partenaire, un export volumineux. Quelques semaines d'observation permettent d'ajuster les règles avant d'activer le filtrage réel.
Ce qu'il ne fait pas
C'est le point le plus important à comprendre avant d'investir. Un pare-feu applicatif reconnaît des formes de requêtes ; il ne comprend pas la logique de votre application.
- Il ne corrige pas une faille : le code vulnérable reste présent, et une requête écrite autrement peut passer.
- Il ne voit pas les défauts de contrôle d'accès : un utilisateur qui consulte le document d'un autre envoie une requête parfaitement normale.
- Il ne protège pas des identifiants volés : la connexion réussit du premier coup.
- Il ne remplace pas les mises à jour : il fait au mieux gagner du temps avant l'application d'un correctif.
Il constitue donc une couche supplémentaire, utile précisément parce qu'elle est indépendante du code, et non un substitut aux mesures décrites dans notre article sur la façon de sécuriser les formulaires.
Les réglages à surveiller
- Les faux positifs : consultez régulièrement ce qui est bloqué, un visiteur légitime ne signale pas toujours son problème ;
- L'adresse réelle des visiteurs : sans configuration adaptée, vos journaux n'enregistrent plus que l'adresse du filtre, ce qui gêne toute analyse ;
- Le contournement direct : si votre serveur reste joignable en dehors du filtre, celui-ci perd son intérêt ;
- Les alertes : un pic de requêtes bloquées est une information, encore faut-il que quelqu'un la reçoive.
NexSecure met en place et règle ce filtrage dans le cadre de l'hébergement web.
Questions fréquentes
Un pare-feu applicatif est-il indispensable ?
Il n'est pas obligatoire, mais il apporte un gain réel face aux attaques automatisées, qui représentent l'essentiel du bruit reçu par un site. Il vient toutefois après les mises à jour, les accès protégés et les sauvegardes.
Ralentit-il le site ?
L'analyse ajoute un délai généralement imperceptible. Lorsqu'il est couplé à un réseau de diffusion de contenu, l'effet est souvent inverse : les pages se chargent plus vite pour les visiteurs éloignés du serveur.
Protège-t-il contre un déni de service ?
Partiellement. Les offres en amont absorbent une partie des attaques par saturation, grâce à leur capacité réseau. Un module installé sur votre propre serveur n'apporte rien dans ce cas, puisque le lien est saturé avant lui.
Peut-il bloquer de vrais visiteurs ?
Oui, c'est le principal effet indésirable. Un formulaire au contenu inhabituel ou un échange automatisé peut être pris pour une attaque. D'où l'intérêt du mode observation initial et d'une revue régulière des blocages.
Sources
Service lié
Articles liés
Rédigé par l'équipe NexSecure. Responsable de la publication : Yohann Toumine. Dernière mise à jour le 11 septembre 2026.
Une question sur votre situation ? Parler de votre projet