Chaque jour, des millions de sites web et d’API sont sondés par des robots malveillants à la recherche de la moindre faille : le WAF, ou Web Application Firewall, est précisément la brique de sécurité chargée de filtrer ce trafic hostile avant qu’il n’atteigne vos applications.
Que vous hébergiez un site WordPress pour votre entreprise, une API REST consommée par une application mobile, ou encore un intranet exposé à vos collaborateurs en télétravail, le WAF a sa place dans votre architecture. Il agit comme un filtre applicatif positionné entre les utilisateurs et votre serveur web, dans le but de bloquer les attaques telles que les injections SQL ou le Cross-Site Scripting (XSS).
Dans cet article, nous allons découvrir ce qu’est un WAF, comprendre son fonctionnement, le situer par rapport aux autres équipements de sécurité (pare-feu réseau, IPS), passer en revue son rôle face aux cyberattaques les plus courantes, puis présenter les principales solutions open source du marché. Enfin, nous terminerons par une mise en pratique volontairement très simple : le déploiement d’un WAF basé sur le moteur ModSecurity et les règles OWASP Core Rule Set, à l’aide d’un conteneur Docker.
Cet article s’adresse aux débutants : aucun prérequis particulier n’est nécessaire, si ce n’est quelques notions sur le fonctionnement du protocole HTTP et des serveurs web.
Qu’est-ce qu’un WAF ?
Un WAF, pour Web Application Firewall (pare-feu applicatif web en français), est une solution de sécurité dont le rôle est d’analyser le trafic HTTP et HTTPS échangé entre les clients (navigateurs, applications mobiles, scripts, robots…) et une application web, afin de détecter et de bloquer les requêtes malveillantes. Autrement dit, il s’agit d’un pare-feu spécialisé dans la protection des applications web.
Contrairement à un pare-feu réseau classique qui raisonne en termes d’adresses IP, de ports et de protocoles, le WAF travaille au niveau applicatif, c’est-à-dire la couche 7 du modèle OSI (que vous connaissez tous par cœur). Ainsi, il est capable de “comprendre” le contenu d’une requête HTTP : l’URL demandée, les en-têtes, les cookies, les paramètres passés dans l’URL ou dans le corps de la requête, etc. C’est grâce à cette analyse en profondeur qu’il peut repérer une tentative d’injection SQL dissimulée dans un champ de formulaire, là où un pare-feu réseau ne verrait qu’un banal paquet à destination du port 443.
Le WAF peut prendre plusieurs formes :
Un boîtier physique (appliance) : installé dans le datacenter, en coupure devant les serveurs web. C’est l’approche historique, que l’on retrouve chez des éditeurs comme F5 ou Fortinet.
Une appliance virtuelle ou un logiciel : déployé sur un hyperviseur ou directement sur le serveur web, sous la forme d’un module (ModSecurity pour Apache, par exemple) ou intégré en tant que module dans un reverse proxy.
Un service cloud (WAF as a Service) : proposé par des entreprises comme Cloudflare, AWS (AWS WAF), Azure (Azure WAF) ou Akamai. Le trafic du site passe par l’infrastructure du fournisseur de services, qui filtre les requêtes avant de les transmettre au serveur d’origine. Le filtrage s’effectue en amont.
Quel que soit le format retenu, le principe reste identique : le WAF s’intercale sur le chemin des requêtes HTTP/HTTPS et joue le rôle de filtre.
Voici un schéma illustrant la position d’un WAF dans une architecture web :
À quoi sert un WAF ?
La mission principale d’un WAF est de protéger les applications web contre les attaques applicatives, c’est-à-dire celles qui exploitent des failles dans le code de l’application elle-même ou dans ses composants (CMS, plugins, frameworks, bibliothèques…).
Concrètement, un WAF répond à plusieurs besoins :
Bloquer les attaques connues : injections SQL, XSS, inclusion de fichiers (LFI/RFI), traversée de répertoires (path traversal), injection de commandes, etc. Le WAF s’appuie sur des règles de détection, comparables aux signatures d’un antivirus.
Protéger les applications vulnérables en attendant un correctif : c’est ce que l’on appelle le virtual patching. Lorsqu’une vulnérabilité est découverte dans une application (par exemple, une faille dans un plugin WordPress), il n’est pas toujours possible de la corriger immédiatement. Une règle WAF spécifique permet alors de bloquer les tentatives d’exploitation, le temps que le correctif officiel soit déployé.
Filtrer les robots malveillants : scanners de vulnérabilités, robots de brute force sur les pages de connexion, scrapers agressifs… Une part importante du trafic web mondial est générée par des robots, et tous ne sont pas bienveillants.
Limiter le débit des requêtes (rate limiting) : pour ralentir les attaques par force brute ou atténuer certaines attaques par déni de service applicatif (DoS de couche 7).
Apporter de la visibilité : les journaux du WAF constituent une source d’information précieuse pour comprendre qui attaque quoi, à quelle fréquence et avec quelles techniques. Ces journaux peuvent alimenter un SIEM.
Répondre à des exigences de conformité : certaines normes mentionnent explicitement le WAF comme mesure de protection des applications web exposées.
Un point mérite d’être souligné dès maintenant : le WAF est un filet de sécurité complémentaire, et non un substitut au développement sécurisé. Une application truffée de vulnérabilités derrière un WAF reste une application vulnérable : le WAF réduit la surface d’exposition, mais il ne corrige pas le code.
WAF, pare-feu réseau et IPS : quelles différences ?
Pour un débutant, il est facile de confondre le WAF avec d’autres équipements de sécurité. Voici comment les distinguer :
Le pare-feu réseau (firewall) travaille principalement sur les couches 3 et 4 du modèle OSI. Il autorise ou bloque le trafic en fonction d’adresses IP source/destination, de ports et de protocoles. Il répond à la question : “Cette machine a-t-elle le droit de parler à ce serveur sur ce port ?”. En revanche, il est incapable d’analyser le contenu d’une requête HTTP : si le port 443 est ouvert, une injection SQL passera comme n’importe quelle autre requête.
L’IDS/IPS (Intrusion Detection/Prevention System) analyse le trafic réseau à la recherche de signatures d’attaques, tous protocoles confondus (SMB, DNS, HTTP…). Il offre une couverture large, mais généraliste : il ne dispose pas de la connaissance fine du protocole HTTP et du contexte applicatif dont bénéficie un WAF.
Le WAF est un spécialiste : il ne s’occupe que du trafic HTTP/HTTPS, mais il le fait en profondeur. Il décode les requêtes, normalise les encodages (URL encoding, Base64, etc.), inspecte chaque paramètre et applique des règles spécifiques aux attaques web.
Parfois, la barrière entre un pare-feu réseau et un WAF semble très fine. C’est normal, un même équipement peut accomplir l’ensemble de ces fonctions via des modules indépendants (notamment des appliances réseau). Le fait qu’elles soient regroupées et activables en même temps prouve bien qu’il y a une complémentarité entre ces différentes solutions de sécurité.
En effet, ces trois briques ne s’opposent pas : elles se complètent dans une logique de défense en profondeur. Le pare-feu réseau filtre le trafic en périphérie, l’IPS surveille les flux internes et le WAF protège spécifiquement les applications web.
Le mode de déploiement : le reverse proxy
Dans la majorité des cas, le WAF fonctionne en mode reverse proxy : il reçoit les requêtes des clients à la place du serveur web, les analyse, puis les transmet (ou non) au serveur d’origine, appelé “backend”. Le client ne communique jamais directement avec l’application : c’est le WAF qui termine la connexion TLS, ce qui lui permet d’inspecter le trafic chiffré en clair. Ce mode d’utilisation est très souvent utilisé.
D’autres modes existent, comme le mode “bridge” (transparent, sans modification de l’adressage) ou le déploiement en module directement intégré au serveur web (c’est le cas de ModSecurity avec Apache), mais le reverse proxy reste le modèle le plus répandu, notamment pour les WAF cloud.
Les modèles de sécurité : liste noire et liste blanche
Un WAF peut appliquer deux logiques de filtrage, souvent combinées :
Le modèle de sécurité négative (liste noire) : le WAF laisse passer tout le trafic, sauf ce qui correspond à des motifs d’attaques connus. C’est le fonctionnement des jeux de règles comme l’OWASP Core Rule Set : des centaines de règles décrivent des motifs caractéristiques d’injections SQL, de XSS, etc. Avantage : rapide à mettre en place. Inconvénient : les attaques inconnues ou habilement obfusquées peuvent passer.
Le modèle de sécurité positive (liste blanche) : le WAF bloque tout, sauf ce qui est explicitement décrit comme légitime (par exemple : “le paramètre id de la page /produit ne peut contenir qu’un entier de 1 à 6 chiffres”). C’est le modèle le plus robuste, mais aussi le plus coûteux à construire et à maintenir, car il exige une connaissance précise de l’application. Le fonctionnement par liste noire est plus souvent utilisé.
Les WAF modernes complètent ces approches par des mécanismes d’apprentissage automatique et de scoring : plutôt que de bloquer dès la première règle déclenchée, chaque anomalie ajoute des points à un score, et la requête n’est bloquée que si le score dépasse un seuil. C’est le principe du “mode anomaly scoring” du Core Rule Set, qui permet de limiter les faux positifs.
Les actions possibles
Lorsqu’une requête déclenche une règle, le WAF peut réagir de plusieurs manières : journaliser l’évènement sans bloquer (mode détection, idéal en phase de test), bloquer la requête avec un code HTTP 403, rediriger le client, présenter un défi (CAPTCHA, challenge JavaScript), ou encore bannir temporairement l’adresse IP source.
La distinction entre mode détection et mode blocage est importante en pratique : on déploie généralement un WAF en mode détection pendant quelques jours ou semaines, on analyse les journaux pour identifier les faux positifs, on ajuste les règles, puis on bascule en mode blocage.
Le rôle du WAF face aux cyberattaques
Le WAF est en première ligne face aux attaques Web à destination des applications, dont les plus répandues sont répertoriées dans le Top 10 de l’OWASP (Open Worldwide Application Security Project), une référence dans le domaine de la sécurité des applications web.
Voyons les principales menaces qu’un WAF est en mesure de contrer.
L’injection SQL (SQLi)
L’attaquant insère du code SQL dans un champ de formulaire ou un paramètre d’URL, dans l’espoir que l’application le transmette tel quel à la base de données. Exemple classique : le paramètre ?id=1′ OR ‘1’=’1 ajouté à une URL. Ici, l’idée étant d’injecter une condition qui est forcément vraie (comme 1 qui est égal à 1).
Si l’application est vulnérable, l’attaquant peut lire, modifier ou supprimer des données, voire prendre le contrôle du serveur de l’application Web. Le WAF détecte les motifs caractéristiques du langage SQL (UNION SELECT, OR 1=1, commentaires –, etc.) dans les paramètres des requêtes, y compris lorsqu’ils sont encodés.
Le Cross-Site Scripting (XSS)
Ici, l’attaquant injecte du code JavaScript malveillant qui sera exécuté dans le navigateur des autres visiteurs, par exemple via un commentaire de blog non filtré. Les conséquences vont du vol de cookies de session au défacement de la page. Le WAF repère les balises et fonctions suspectes (, onerror=, javascript:, etc.) dans les données soumises.
L’inclusion de fichiers et la traversée de répertoires
Les attaques de type LFI (Local File Inclusion) ou path traversal consistent à manipuler des paramètres pour accéder à des fichiers sensibles du serveur, comme /etc/passwd, via des séquences du type ../../../. Le WAF bloque ces motifs après avoir normalisé les différents encodages possibles. Il est également possible de limiter ce type de séquence au niveau des paramètres du serveur Web.
L’injection de commandes
Lorsqu’une application exécute des commandes système à partir d’entrées utilisateur, un attaquant peut tenter d’y injecter ses propres commandes (; cat /etc/passwd, | whoami…). Là encore, le WAF détecte les caractères et mots-clés caractéristiques.
Les attaques par brute force et le credential stuffing
Le WAF peut limiter le nombre de tentatives de connexion par adresse IP sur une période donnée (rate limiting), et ainsi ralentir considérablement les attaques visant à deviner des mots de passe ou à rejouer des identifiants volés. Dans le cas présent, c’est aussi à l’application elle-même de détecter le nombre de tentatives infructueuses et de bloquer les adresses IP malveillantes. Si l’on prend l’exemple du CMS WordPress, il existe des plugins capables d’accomplir cette tâche.
L’exploitation de vulnérabilités connues (CVE)
Lorsqu’une vulnérabilité majeure est divulguée, les éditeurs de règles WAF publient rapidement des signatures de détection. Les organisations protégées par un WAF à jour bénéficient ainsi d’une protection avant même d’avoir patché leurs applications. C’est l’un des arguments forts en faveur du WAF : il fait gagner du temps aux équipes techniques.
Récemment, je me souviens qu’il y avait eu des règles de Virtual Patching pour la faille de sécurité React2Shell.
Les limites du WAF
Il faut aussi connaître les limites de WAF, qui, je vous le rappelle, n’élimine pas la nécessité de faire du développement sécurisé et de maintenir à jour vos applications.
Les faux positifs : des requêtes légitimes peuvent être bloquées, par exemple un article de blog qui parle… d’injection SQL (j’ai déjà eu des blocages de ce type quand l’URL d’un article contient des mots clés sensibles). Un WAF mal réglé peut perturber le fonctionnement de l’application, d’où l’intérêt de la phase de rodage en mode détection.
Les techniques de contournement : les attaquants rivalisent d’ingéniosité pour obfusquer leurs charges utiles (encodages multiples, fragmentation, variations syntaxiques) et passer sous le radar des règles.
Les failles logiques : un WAF ne peut pas détecter une faille de logique métier, comme un contrôle d’accès défaillant qui permettrait à un utilisateur de consulter les factures d’un autre client. La requête est syntaxiquement parfaitement légitime.
La maintenance : un WAF demande un suivi régulier : mise à jour des règles, analyse des journaux, ajustement des exclusions.
Le WAF doit donc s’inscrire dans une démarche globale : développement sécurisé, gestion des correctifs, tests d’intrusion réguliers et supervision. Il faut garder à l’esprit qu’il existe des techniques pour identifier le WAF utilisé pour protéger une application (notamment via l’analyse des en-têtes HTTP retournés). À ce propos, vous pourrez trouver des informations supplémentaires sur ce dépôt GitHub.
Les solutions WAF open source
Le monde de l’open source propose plusieurs solutions de qualité pour déployer un WAF. Voici quelques exemples.
ModSecurity et l’OWASP Core Rule Set
ModSecurity est le moteur WAF open source historique, créé en 2002. Il fonctionne comme un module pour Apache, et des connecteurs existent pour Nginx et IIS. ModSecurity ne fait “que” exécuter des règles : sa valeur vient du jeu de règles qui l’accompagne, et le plus connu est l’OWASP Core Rule Set (CRS), un ensemble de règles génériques maintenu par la communauté, qui couvre les grandes familles d’attaques (SQLi, XSS, LFI, RCE…).
Configurer ModSecurity n’est pas une mince affaire, mais c’est un projet de référence.
Coraza
OWASP Coraza est un moteur WAF moderne écrit en Go, entièrement compatible avec la syntaxe des règles ModSecurity et 100% compatible avec le Core Rule Set v4. Il s’intègre notamment avec le serveur web Caddy, avec les proxys basés sur Envoy, et peut être embarqué dans des applications Go. Il y a également un plugin Coraza pour Traefik et pour HAProxy.
BunkerWeb
BunkerWeb est une solution open source française qui repose sur Nginx et l’enrichit avec de nombreuses protections prêtes à l’emploi : intégration de ModSecurity (une façon beaucoup plus digeste de l’utiliser) et du Core Rule Set, listes noires d’IP, limitation de débit, protection anti-bot, gestion automatique des certificats Let’s Encrypt… Le tout avec une interface web d’administration. C’est une option intéressante pour obtenir rapidement un reverse proxy durci.
Un tutoriel complet a déjà été publié sur IT-Connect :
open-appsec
open-appsec est un WAF open source basé sur l’apprentissage automatique, développé par Check Point. Il se distingue par son approche sans signatures : il apprend le trafic légitime de l’application et détecte les anomalies, ce qui le rend capable de bloquer des attaques inédites (zero-day). Il s’intègre avec Nginx, Kubernetes (ingress) et d’autres environnements comme Nginx Proxy Manager et les outils Envoy.
SafeLine
SafeLine est un WAF open source qui a gagné en popularité ces dernières années. Il s’appuie sur une analyse sémantique des requêtes plutôt que sur des signatures classiques. C’est un projet open source qui semble trouver ses origines en Chine.
Mise en pratique : déployer un WAF avec Docker en quelques minutes
Place à la pratique ! L’objectif est de monter la maquette la plus simple possible : un WAF ModSecurity + OWASP Core Rule Set, déployé en reverse proxy devant un petit site web de démonstration, le tout avec Docker. Cette maquette permettra de découvrir le comportement d’un WAF.
Étape 1 : créer le projet Docker Compose
Sur une machine disposant de Docker et de Docker Compose, créez un répertoire pour ce projet et un fichier docker-compose.yml. J’ai l’habitude de travailler sous /opt/docker-compose.
mkdir /opt/docker-compose/lab-waf && cd /opt/docker-compose/lab-waf
nano docker-compose.yml
Ajoutez le contenu suivant au fichier YAML :
services:
backend:
image: nginxdemos/hello:plain-text
container_name: site-backend
waf:
image: owasp/modsecurity-crs:nginx
container_name: waf-modsecurity
ports:
– “8080:8080”
environment:
# Adresse du serveur à protéger (à savoir notre backend)
BACKEND: “http://backend”
# Mode du moteur : DetectionOnly ou On (blocage)
MODSEC_RULE_ENGINE: “On”
# Niveau de paranoïa du CRS (1 = le moins de faux positifs)
PARANOIA: “1”
depends_on:
– backend
Ici, nous utilisons l’image officielle owasp/modsecurity-crs:nginx qui embarque Nginx, le moteur ModSecurity et le Core Rule Set préconfigurés. La variable BACKEND indique vers quel serveur relayer les requêtes légitimes, donc nous indiquons le nom du conteneur où est exécuté notre site web. La variable MODSEC_RULE_ENGINE positionnée sur On active le blocage (utilisez DetectionOnly pour un mode passif qui se contente de journaliser).
Étape 2 : démarrer la maquette
Exécutez la commande suivante depuis le répertoire du projet.
docker compose up -d
Vérifiez que les deux conteneurs sont bien démarrés :
docker compose ps
Vous devriez obtenir ce résultat :
Étape 3 : tester une requête légitime
Depuis la machine hôte, interrogez le site de démonstration au travers du WAF (vous remarquerez que le conteneur du site web n’est pas exposé de toute façon). Ici, je cible 192.168.10.200 car il s’agit de l’adresse de mon serveur Docker.
curl -i http://192.168.10.200:8080/
Le serveur backend répond avec un code HTTP/1.1 200 OK : la requête est légitime, le WAF l’a laissée passer et a relayé la réponse.
Étape 4 : simuler des attaques
Simulons maintenant une tentative d’injection SQL dans un paramètre d’URL :
curl -i “http://192.168.10.200:8080/?id=1%27%20OR%20%271%27=%271”
# De façon plus lisible :
curl -i “http://192.168.10.200:8080/?id=1′ OR ‘1’=’1”
Cette fois, la réponse est sans appel : HTTP/1.1 403 Forbidden. La requête n’a jamais atteint le backend, elle a été bloquée par le WAF. Il a interdit l’accès à ce client malveillant.
Essayons une tentative de traversée de répertoires en cherchant à lire un fichier système :
curl -i “http://192.168.10.200:8080/?file=../../../../etc/passwd”
Dans les deux cas, le verdict est identique : 403 Forbidden. Voyez par vous-même :
Étape 5 : consulter les journaux du WAF
Pour comprendre pourquoi une requête a été bloquée, consultez les journaux du conteneur :
docker compose logs waf | grep ModSecurity
Vous y trouverez, pour chaque blocage, la ou les règles déclenchées (identifiées par leur ID, par exemple 942100 pour la détection d’injection SQL via la bibliothèque libinjection), le score d’anomalie atteint et le détail de la charge utile détectée. C’est exactement ce type d’information que vous exploiterez au quotidien pour ajuster votre configuration et traiter les faux positifs.
Voici un exemple (tronqué pour plus de clareté) :
{
“transaction”: {
“client_ip”: “192.168.10.199”,
“time_stamp”: “Tue Jun 16 08:17:03 2026”,
“is_interrupted”: true,
“request”: {
“method”: “GET”,
“uri”: “/?id=1%27%20OR%20%271%27=%271”
},
“response”: {
“http_code”: 403
},
“producer”: {
“modsecurity”: “ModSecurity v3.0.15 (Linux)”,
“components”: [“OWASP_CRS/4.25.0”]
},
“messages”: [
{
“message”: “Host header is a numeric IP address”,
“details”: {
“ruleId”: “920350”,
“data”: “192.168.10.200:8080”,
“severity”: “4”
}
},
{
“message”: “SQL Injection Attack Detected via libinjection”,
“details”: {
“ruleId”: “942100”,
“data”: “Matched Data: s&sos found within ARGS:id: 1′ OR ‘1’=’1”,
“severity”: “2”
}
},
{
“message”: “Inbound Anomaly Score Exceeded (Total Score: 8)”,
“details”: {
“ruleId”: “949110”,
“match”: “Operator `Ge’ with parameter `5′ against TX:BLOCKING_INBOUND_ANOMALY_SCORE (Value: `8′)”
}
}
]
}
}
Trois règles se sont déclenchées, et c’est leur cumul de score qui aboutit au 403. Nous retrouvons :
Règle 942100 – SQL Injection Attack Detected via libinjection (gravité 2 = CRITICAL). C’est la détection de fond : elle a repéré l’injection SQL dans le paramètre id. Son severity CRITICAL vaut 5 points dans le barème du CRS.
Règle 920350 – Host header is a numeric IP address (gravité 4 = WARNING). Elle se plaint que l’en-tête Host est une adresse IP (192.168.10.200:8080) et non un nom de domaine. WARNING vaut 3 points.
Règle 949110 – Inbound Anomaly Score Exceeded (Total Score: 8). Celle-ci ne détecte rien : elle compare le score cumulé (8) au seuil de blocage. Le Matched “Operator Ge with parameter 5” indique que le seuil est 5. Comme 8 > 5, la requête est interrompue. Aussi, cet exemple montre que l’injection SQL à elle seule suffirait à bloquer la requête puisque 5 > 4.
Côté client, nous avons eu un retour HTTP avec un code 403, ce qui est cohérent avec cette mention visible dans les logs : “is_interrupted”: true et “http_code”: 403.
Pour aller plus loin
Cette maquette tient volontairement en un seul fichier, mais elle illustre les concepts essentiels : le reverse proxy, le jeu de règles, le mode de blocage et la journalisation. Pour un usage réel, il faudrait notamment : activer le HTTPS sur le WAF, ajuster le niveau de paranoïa du CRS, mettre en place des exclusions pour les faux positifs propres à votre application, centraliser les journaux et superviser l’ensemble.
L’image owasp/modsecurity-crs propose de nombreuses variables d’environnement pour cela, documentées sur le dépôt GitHub officiel du projet.
Conclusion
Le WAF est un maillon à part entière de la sécurité des applications web : positionné en coupure entre les clients et les serveurs, il analyse le trafic HTTP/HTTPS en profondeur et bloque les attaques applicatives les plus répandues, des injections SQL au XSS, en passant par l’exploitation de vulnérabilités fraîchement divulguées grâce au virtual patching.
Nous avons vu qu’il ne remplace ni le pare-feu réseau, ni les bonnes pratiques de développement, ni la gestion des correctifs : il les complète, dans une logique de défense en profondeur. Nous avons également passé en revue les principales solutions open source (ModSecurity, Coraza, NAXSI, open-appsec, BunkerWeb, SafeLine), qui permettent de s’équiper sans budget licence, et démontré avec une maquette Docker qu’un premier WAF fonctionnel se déploie en quelques minutes.
Si vous débutez, la meilleure approche consiste à reproduire ce lab, à observer les journaux, puis à expérimenter le mode détection, les niveaux de paranoïa du Core Rule Set et la gestion des faux positifs. Vous serez alors armé pour envisager sereinement un déploiement en conditions réelles.
FAQ – Foire aux questions sur les WAF
Qu’est-ce qu’un WAF en cybersécurité ?
Un WAF (Web Application Firewall) est un pare-feu applicatif qui analyse le trafic HTTP/HTTPS entre les clients et une application web afin de détecter et de bloquer les requêtes malveillantes, comme les injections SQL ou les attaques XSS.
Quelle est la différence entre un WAF et un pare-feu classique ?
Le pare-feu réseau filtre le trafic selon les adresses IP, les ports et les protocoles (couches 3 et 4 du modèle OSI), tandis que le WAF inspecte le contenu des requêtes HTTP au niveau applicatif (couche 7) : URL, en-têtes, cookies et paramètres.
Un WAF protège-t-il contre toutes les cyberattaques ?
Protège-t-il contre les cyberattaques : Oui. Contre toutes les cyberattaques ? Non. Le WAF bloque les attaques web à destination de vos applications. Il ne protège pas contre le phishing, les malwares sur les postes de travail, les failles de logique métier ou les attaques visant d’autres protocoles. Il s’inscrit dans une stratégie de défense en profondeur.
Qu’est-ce que l’OWASP Core Rule Set (CRS) ?
C’est un jeu de règles de détection open source maintenu par la communauté OWASP, compatible avec plusieurs WAF dont ModSecurity et Coraza. Il couvre les grandes familles d’attaques web : injection SQL, XSS, inclusion de fichiers, injection de commandes, etc.
Qu’est-ce que le virtual patching ?
Le virtual patching consiste à déployer une règle WAF qui bloque l’exploitation d’une vulnérabilité connue, en attendant que le correctif officiel soit appliqué sur l’application. Cela réduit la fenêtre d’exposition sans modifier le code.
Qu’est-ce qu’un faux positif sur un WAF ?
Il s’agit d’une requête légitime bloquée à tort, car elle ressemble à une attaque. Par exemple, un formulaire où l’utilisateur saisit du code SQL dans un cadre pédagogique. Les faux positifs se traitent par des règles d’exclusion ciblées.
Un WAF peut-il protéger une API REST ?
Oui. Les API utilisent le protocole HTTP et bénéficient donc du filtrage du WAF. Certaines solutions proposent en complément la validation de schémas OpenAPI, pour n’accepter que les requêtes conformes à l’API.
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.