Ce qu'est un WAF et ce qu'il bloque
Un Web Application Firewall (WAF) se positionne entre vos visiteurs et votre application web, inspectant chaque requête entrante et décidant de l'autoriser, de la bloquer ou de la mettre au défi. Contrairement à un pare-feu réseau traditionnel qui ne regarde que les adresses IP et les ports, un WAF comprend le trafic web réel — les URL, les en-têtes, les cookies et les données de formulaire — ce qui lui permet de repérer les attaques visant votre application elle-même.
Il est conçu pour stopper les menaces web les plus courantes : l'injection SQL (qui piège votre base de données), le cross-site scripting ou XSS (l'injection de scripts malveillants), le path traversal, et les bots malveillants ou abusifs. Ses jeux de règles suivent généralement l'OWASP Top 10, la liste de référence du secteur des risques les plus critiques pour les applications web.
Comment un WAF fonctionne réellement
Lorsqu'une requête arrive, le WAF l'évalue par rapport à un ensemble de règles avant qu'elle n'atteigne votre application. Ces règles combinent des signatures d'attaques connues (motifs d'injection SQL, de XSS et similaires), des données de réputation (IP et botnets connus comme malveillants), et des limites comportementales comme le rate limiting pour ralentir le brute-force et le scraping. Selon le résultat, il autorise la requête, la bloque, ou la met au défi (par exemple avec une vérification permettant de distinguer les humains des bots).
Comme il opère au niveau de la couche 7 (Layer 7), le WAF peut prendre des décisions qu'un pare-feu réseau ne peut pas — par exemple, autoriser le trafic normal vers une page de connexion tout en bloquant une requête porteuse d'une charge d'injection. Les bons WAF permettent d'exécuter les règles en mode surveillance (monitor mode) d'abord, afin de voir ce qui serait bloqué avant de l'appliquer réellement.
WAF en périphérie ou à l'origine : pourquoi l'emplacement compte
Un WAF exécuté en périphérie du CDN inspecte et bloque les requêtes malveillantes à la couche externe du réseau — proche de l'attaquant et loin de votre serveur. Le trafic malveillant est éliminé avant même de consommer le CPU, la base de données ou la bande passante de votre origine, et la même périphérie qui filtre les attaques absorbe aussi les inondations DDoS volumétriques grâce à sa capacité globale.
Un WAF qui ne fonctionne que sur votre propre serveur (ou sous forme de plugin) doit d'abord recevoir et traiter chaque requête, si bien que les attaques et les inondations atteignent votre infrastructure avant d'être filtrées. Placer la sécurité en périphérie signifie que votre serveur consacre ses ressources aux visiteurs réels, et non à repousser des attaques.
Ajustement : la sécurité sans faux positifs
La partie difficile de tout WAF est de bloquer les attaques sans bloquer les vrais clients. Des règles trop strictes peuvent signaler des soumissions de formulaires ou des appels API légitimes comme des attaques (un faux positif), tandis que des règles trop souples laissent passer les menaces. L'approche pratique consiste à démarrer en mode surveillance, observer ce que les règles intercepteraient, puis les affiner et ajouter des allowlists pour les chemins ou paramètres spécifiques dont votre application a besoin.
Cet ajustement est un travail continu, ce qui explique la valeur d'un WAF géré : les règles, les signatures et les seuils DDoS sont maintenus pour vous et mis à jour à mesure que de nouvelles menaces apparaissent, afin que vous bénéficiiez d'une protection sans avoir à devenir ingénieur en sécurité.
Quand un WAF est le plus important
Partout où les utilisateurs soumettent des données — paiement, formulaires de contact, connexion — constitue une cible pour les attaques par injection et par identifiants qu'un WAF est conçu pour arrêter.
Un WAF bloque les scrapers, le credential stuffing et les bots de spam qui volent du contenu et gaspillent les ressources de votre serveur.
Un WAF en périphérie associé à une protection DDoS vous maintient en ligne pendant les inondations en filtrant et en absorbant le trafic avant qu'il ne vous atteigne.
FAQ WAF
Quelle est la différence entre un WAF et un pare-feu classique ?
Un pare-feu réseau filtre le trafic par adresse IP et par port (couches 3-4). Un WAF agit au niveau de la couche applicative (Layer 7) : il comprend les requêtes HTTP et bloque les attaques au niveau applicatif, comme l'injection SQL et le XSS, qu'un pare-feu réseau ne peut pas voir.
Ai-je besoin d'un WAF si j'ai déjà SSL/HTTPS ?
Oui — ils remplissent des rôles différents. SSL/TLS chiffre le trafic afin qu'il ne puisse pas être lu en transit ; un WAF inspecte ce trafic à la recherche d'attaques. Une requête chiffrée peut toujours porter une charge d'injection, c'est exactement ce que le WAF est là pour détecter.
Un WAF va-t-il ralentir mon site ?
Un WAF en périphérie ajoute une latence négligeable et peut même rendre votre site plus rapide en éliminant le trafic indésirable avant qu'il n'atteigne votre serveur. Il fonctionne aux côtés du cache CDN, si bien que les visiteurs légitimes continuent d'être servis depuis la périphérie.
Un WAF va-t-il bloquer de vrais visiteurs ?
Un WAF bien ajusté minimise les faux positifs en démarrant en mode surveillance et en utilisant des allowlists pour les chemins légitimes de votre application. Un WAF géré prend en charge cet ajustement et maintient les règles à jour afin que vos vrais clients puissent accéder au site.