🎓 Niveau : 🔴 Avancé
📋 Prérequis : bases HTTP/HTTPS, notion de requête web, idéalement IPS
WAF signifie Web Application Firewall (« pare-feu d'application web »). C'est un filtre spécialisé qui se place devant un site ou une API et inspecte chaque requête HTTP pour bloquer celles qui sont malveillantes (injection SQL, XSS, etc.). Là où un pare-feu classique raisonne en ports/IP et un IPS en paquets réseau, le WAF comprend le langage du web (URL, en-têtes, formulaires, JSON).
La plupart des attaques modernes visent directement les applications web : elles arrivent par le port 443 (HTTPS), parfaitement « autorisé » par le pare-feu, et exploitent des failles du code de l'application.
Exemples : une injection SQL qui vole une base de données, un XSS (Cross-Site Scripting) qui détourne la session d'un utilisateur. Ni le pare-feu (qui ne lit pas le contenu HTTP) ni toujours l'IPS réseau ne comprennent assez finement ces attaques applicatives.
Le problème : il faut un gardien qui parle HTTP, sait ce qu'est un paramètre de formulaire, un cookie, un corps JSON — et reconnaît qu'une valeur contient une injection. C'est exactement le rôle du WAF.
Bonus : un WAF permet de protéger une appli vulnérable le temps de corriger le code (« patch virtuel »), ce qui fait gagner un temps précieux.
- Requête HTTP : message qu'un navigateur envoie à un serveur web (méthode
GET/POST, URL, en-têtes, corps). Le WAF analyse tout ce contenu.
- Injection SQL : attaque qui glisse du code SQL dans un champ pour manipuler la base de données.
- XSS (Cross-Site Scripting) : injection de code JavaScript malveillant dans une page, exécuté chez les autres visiteurs.
- OWASP Top 10 : liste de référence des 10 risques de sécurité web les plus courants, publiée par l'OWASP (Open Web Application Security Project). Les WAF s'en inspirent largement.
- Modèle négatif (blacklist) : on bloque ce qui ressemble à une attaque connue (signatures).
- Modèle positif (whitelist) : on n'autorise que ce qui correspond exactement au comportement attendu ; tout le reste est refusé. Plus sûr, plus exigeant à régler.
- Mode détection vs blocage : comme un IPS, le WAF peut juste alerter (audit) ou bloquer (prévention).
- Reverse proxy : serveur intermédiaire placé devant l'application ; le WAF fonctionne très souvent ainsi (le trafic passe par lui avant d'atteindre l'appli).
- Patch virtuel : règle WAF qui bloque l'exploitation d'une faille sans modifier le code de l'application, en attendant le correctif réel.
- Interception : toutes les requêtes web passent d'abord par le WAF (souvent en reverse proxy ou en service cloud devant le site).
- Décodage : le WAF déchiffre le TLS si besoin, puis normalise la requête (décode l'URL, lit les paramètres, le corps JSON…) pour empêcher qu'une attaque se cache sous un encodage.
- Analyse : il applique ses règles — signatures d'attaques (modèle négatif) et/ou comportement autorisé (modèle positif).
- Décision :
- requête saine → transmise à l'application ;
- requête malveillante → bloquée (réponse 403), challengée (CAPTCHA) ou journalisée selon le mode.
- Réponse : la réponse de l'application repasse par le WAF, qui peut aussi masquer des fuites (ex. messages d'erreur trop bavards).
graph LR
USER[Utilisateur / Attaquant] -->|requête HTTP| WAF{WAF reverse proxy}
WAF -->|requête saine| APP[Application web + BDD]
WAF -.->|injection SQL / XSS = 403| BLOCK[bloqué ✋]
APP -->|réponse| WAF
WAF -->|réponse filtrée| USER
WAF -->|logs| SIEM[SIEM]
La PME héberge une boutique en ligne. Elle place ModSecurity (WAF open source) avec le jeu de règles OWASP Core Rule Set devant son serveur web, en reverse proxy.
Un attaquant tente une injection SQL dans le champ de recherche :
GET /recherche?q=' OR '1'='1' --
Le WAF reconnaît le motif d'injection, renvoie un 403 et n'achemine jamais la requête vers la base de données. L'incident part dans le SIEM.
Quelques semaines plus tard, une faille critique est annoncée sur le CMS utilisé. Le correctif éditeur n'arrive que dans 5 jours. L'équipe ajoute aussitôt un patch virtuel au WAF qui bloque le schéma d'exploitation : la boutique reste protégée pendant l'attente du vrai correctif.
- Démarre en mode détection, observe les faux positifs sur ton trafic réel, puis active le blocage.
- Pars d'un socle reconnu comme l'OWASP Core Rule Set plutôt que de tout écrire à la main.
- Le WAF ne remplace pas le code sécurisé. C'est une couche de défense en plus d'un développement propre (requêtes paramétrées, validation des entrées).
- Gère le TLS : sans déchiffrement, le WAF ne voit pas le contenu HTTPS.
- Mets à jour les règles régulièrement (nouvelles attaques, nouveaux CVE).
- Active la limitation de débit (rate limiting) pour freiner brute force et déni de service applicatif.
- Surveille les logs : le WAF révèle qui tente quoi sur ton appli.
Penser que le WAF dispense de coder proprement. Un WAF mal réglé se contourne ; la vraie défense reste un code robuste. Le WAF est une couche, pas une excuse.
Des règles trop strictes qui bloquent de vrais utilisateurs (ex. un champ « commentaire » légitime qui contient < ou '). D'où la phase de détection préalable.
Oublier le déchiffrement TLS : un WAF qui ne voit pas le contenu chiffré ne protège de rien.
- Le WAF filtre le trafic HTTP applicatif (injections, XSS…), là où pare-feu et IPS réseau s'arrêtent.
- Il se place devant l'application (souvent en reverse proxy / cloud) et peut alerter ou bloquer.
- Il complète — sans remplacer — un code sécurisé, et permet le patch virtuel en attendant un correctif.
« Le WAF parle couramment le HTTP — c'est sa langue maternelle. » 🔑