WAF : à quoi sert un pare-feu applicatif et pourquoi il doit être piloté

Le WAF, ce n’est pas un chien qui monte la garde, mais son rôle n’en est pas très éloigné. En informatique, un WAF (Web Application Firewall, ou pare-feu applicatif) est un filtre placé devant un site ou une application web : il inspecte les requêtes HTTP et HTTPS et bloque celles qui sont malveillantes avant qu’elles n’atteignent le serveur.

Le sujet n’a rien de théorique. Selon le Bad Bot Report 2026 d’Imperva, le trafic automatisé a représenté plus de 53 % du trafic web en 2025 : sur Internet, les robots sont désormais plus nombreux que les humains. Une partie d’entre eux est utile, comme les robots des moteurs de recherche. Une autre partie scanne les sites à la recherche de failles, teste des mots de passe ou aspire des catalogues.

Chez Spiriit, nous déployons des WAF pour des sites e-commerce comme pour des sites de génération de leads. Notre conviction : un WAF ne protège durablement que s’il est piloté dans le temps. C’est ce que nous appelons le WAF management.

Qu’est-ce qu’un WAF en informatique ?

Un WAF se place en amont du serveur web, le plus souvent sur une infrastructure dédiée. Il filtre, surveille et bloque le trafic HTTP et HTTPS malveillant à partir de règles de sécurité personnalisées. Sa particularité tient à la profondeur de son analyse : il lit le contenu même des requêtes, au niveau applicatif, c’est-à-dire la couche 7 du modèle OSI.

WAF ou pare-feu réseau : quelle différence ?

Un pare-feu traditionnel se limite aux couches plus basses du réseau : il autorise ou refuse des connexions selon des adresses IP et des ports. Un WAF regarde ce que contient la requête : l’URL appelée, ses paramètres, ses en-têtes ou les données d’un formulaire. Les deux sont complémentaires : le pare-feu réseau protège l’infrastructure, le WAF protège l’application qui tourne dessus.

Ce qu’un WAF permet de filtrer

Un WAF combine deux familles de règles. Les règles gérées, maintenues par l’éditeur du WAF, bloquent les attaques applicatives connues, comme les injections SQL, les scripts intersites (XSS) ou l’exploitation de failles publiées. Les règles personnalisées sont écrites pour un site donné. Avec ces règles personnalisées, il est par exemple possible de filtrer :

• un user agent, comme curl, d’anciennes versions de navigateurs (Firefox 28, Chrome 46) ou des outils de scan comme leakix ;
• un AS (Autonomous System, c’est-à-dire un ensemble de réseaux) connu pour héberger des robots malveillants plutôt que de vrais internautes ;
• une adresse IP, en IPv4 ou en IPv6, ou une plage d’adresses ;
• un pays ;
• une query string, par exemple ?taille=xs,s,m,l.

Sur un site e-commerce, ce dernier exemple compte : des robots peuvent combiner les filtres du catalogue à l’infini et solliciter le serveur sur des pages qu’aucun client ne consultera.

WAF cloud, logiciel ou matériel

Il existe trois grandes familles de WAF. Le WAF matériel est un boîtier installé dans l’infrastructure de l’entreprise. Le WAF logiciel s’installe sur le serveur ou à côté, sous forme de module. Le WAF cloud s’active en faisant passer le trafic du site par le réseau d’un fournisseur, généralement via les DNS. Pour des sites e-commerce et des sites vitrines, le WAF cloud est le plus simple à déployer, et il filtre le trafic indésirable avant même qu’il n’arrive chez l’hébergeur. C’est l’option que nous avons retenue.

Pourquoi nous avons choisi Cloudflare

Chez Spiriit, nous nous appuyons sur Cloudflare. Selon nous, le service représente l’état de l’art de la protection des sites web. Il combine plusieurs outils qui démultiplient nos possibilités de filtrage et de suivi, et il permet aussi de protéger des accès ou d’héberger des pages web. Son réseau donne une idée de l’échelle : selon Cloudflare, environ un site sur cinq sur Internet utilise ses services, son réseau dispose de près de 500 Tbps de capacité, et 95 % de la population connectée se trouve à moins de 50 millisecondes de l’un de ses datacenters.

Son offre gratuite suffit à protéger la plupart des sites de génération de leads, souvent sous WordPress et forcément visés par des robots malveillants. Pour les sites e-commerce, nous recommandons de passer sur l’offre Pro, avec la même stratégie de protection. La différence est concrète : le plan gratuit permet 5 règles personnalisées et donne accès à une partie seulement des règles gérées par Cloudflare. Le plan Pro monte à 20 règles personnalisées et ouvre l’accès au jeu complet de règles gérées, dont le Cloudflare OWASP Core Ruleset.

Le service a fait ses preuves : depuis que nous l’utilisons, il nous a permis de protéger plusieurs clients contre de multiples attaques de robots avec succès.

Filtrer ne veut pas dire bloquer vos clients

En pratique, en quoi consiste ce filtrage ? Sauf rares exceptions, nous ne rejetons pas directement le trafic : nous soumettons l’internaute, ou le robot, à un challenge Cloudflare qui vérifie qu’il s’agit bien d’un humain. Si une personne se trouve derrière l’écran, elle valide le challenge, souvent sans même avoir à agir. Sinon, sa requête est rejetée.

Ce mécanisme laisse passer la quasi-totalité des visiteurs légitimes, avec quelques limites connues. Le navigateur doit accepter JavaScript et les cookies, et un challenge ne fonctionne pas sur certains appels techniques, comme les requêtes qu’une page envoie en arrière-plan. C’est pourquoi chaque règle doit être testée sur le parcours réel du site, panier et paiement compris.

Des règles avancées, à manier avec précaution

Plutôt que de filtrer la terre entière, il est parfois plus efficace de ne laisser passer sans contrôle que les pays légitimes. Prenons un site e-commerce qui vend uniquement en France : nous pouvons créer une règle qui soumet au challenge tout le trafic, sauf celui qui vient de France.

Cette règle cache un piège. Écrite telle quelle, elle filtre aussi les robots utiles, comme Googlebot ou Bingbot, qui utilisent généralement des adresses IP américaines. Cloudflare permet d’exclure les robots vérifiés d’une règle, ce qui évite de pénaliser le référencement. Le risque reste réel pour d’autres services légitimes, comme les prestataires de paiement qui s’appuient sur des services cloud à l’étranger. Un webhook de paiement filtré, c’est une commande qui ne se valide pas. Ces filtres demandent donc une grande vigilance, et chaque client est un cas particulier.

Ce que le WAF fait gagner à votre infrastructure

Le WAF arrête les requêtes malveillantes en bordure du réseau Cloudflare : ce trafic n’atteint jamais le serveur web. Il devient alors possible de dimensionner l’hébergement de façon plus raisonnée, pour répondre à de vrais clients plutôt qu’à des robots qui scannent le web. C’est aussi une démarche plus responsable sur le plan environnemental.

Prenons l’exemple d’un client qui recevait 1,2 million de requêtes sur 24 heures. Le WAF en a bloqué près de 700 000 et le cache de Cloudflare en a servi 100 000 (ce point peut encore être amélioré). Le serveur n’a finalement eu à traiter que 412 000 requêtes, soit une réduction d’environ 65 %. Le WAF représente l’essentiel de ce gain, avec un peu plus de la moitié des requêtes écartées, et le cache fait le reste. Dimensionner une infrastructure pour absorber plus d’un million de requêtes quotidiennes ou pour en traiter 400 000 n’implique ni la même architecture ni le même coût.

(Insérer ici la capture du cas client.)

Le WAF management : un pare-feu se pilote dans la durée

Le WAF management désigne tout ce qui se passe après l’installation : la surveillance du trafic, l’analyse des journaux et l’ajustement continu des règles. Lors de la mise en place, nous déployons nos règles éprouvées sur le compte Cloudflare du client, gratuit ou payant. Il faut bien sûr les adapter à l’application hébergée pour ne pas filtrer des requêtes importantes, comme un webhook de paiement. Mais le travail ne s’arrête pas là : un WAF doit être surveillé et ajusté au fil des jours, des semaines et des mois. C’est pourquoi notre offre prévoit le maintien en condition opérationnelle du WAF, réalisé sur mesure pour chaque client à partir d’analyses de logs régulières.

Savoir ce qui est filtré, et ce qui devrait l’être

Pour piloter un WAF, il faut savoir ce qu’il filtre, mais aussi ce qu’il devrait filtrer. Pour combler ce besoin, nous avons créé des Workers sur Cloudflare, de petits programmes très légers exécutés directement sur son réseau, qui détectent les signaux faibles de tentatives de scan non couvertes par une règle existante et réagissent selon l’importance de l’attaque. Un DevSecOps peut ainsi vérifier et ajuster les règles quasiment en temps réel. Les journaux de blocage remontent aussi dans nos outils, et un rapport hebdomadaire est envoyé aux équipes pour mesurer l’efficacité des protections.

Nous avons fait le choix de ne pas tout automatiser. Une règle mal calibrée peut bloquer de vrais clients : garder un humain dans la boucle limite au maximum ces faux positifs.

Ce suivi conditionne l’efficacité du WAF dans le temps. Les attaquants adaptent leurs méthodes, notamment grâce à l’IA, et un pare-feu applicatif qui n’est pas mis à jour finit par laisser passer ce qu’il bloquait au départ.

Un bon WAF, c’est d’abord une équipe qui le pilote

Le WAF est un outil important, mais ce sont les personnes qui assurent son maintien en condition opérationnelle qui font la différence. Il peut aussi être combiné à d’autres dispositifs, comme un honeypot, un piège qui permet d’identifier et de mettre sur liste noire les adresses IP hébergeant des robots malveillants. Si vous vous demandez ce que votre site laisse passer aujourd’hui, l’analyse de vos journaux de trafic est un bon point de départ : c’est souvent là qu’apparaît la part réelle des robots.

Vous souhaitez mettre en place un WAF ou confier son pilotage à une équipe dédiée ? Découvrez notre offre de cybersécurité ou contactez-nous pour en parler.