WAF et pare-feu applicatif web : protéger les sites et applications de l’entreprise
WAF et pare-feu applicatif web : ce qu’il bloque, ce qu’il ne voit pas, WAF cloud, équipement ou module serveur, règles OWASP CRS et mise en service sans casser le site.
La réponse courte : un WAF (Web Application Firewall), ou pare-feu applicatif web, se place devant un site ou une application web et analyse chaque requête HTTP et HTTPS pour bloquer les attaques connues : injection SQL, cross-site scripting, inclusion de fichiers, exploitation d’une faille publiée. Il complète le pare-feu réseau, les mises à jour et la double authentification sans les remplacer. On le déploie en service cloud, en équipement ou machine virtuelle dédiée, ou sur le serveur web, et on le met en service en mode détection avant de bloquer, pour éviter de couper des clients légitimes.
Ce guide explique ce qu’un WAF arrête, ce qu’il ne voit pas, comment choisir sa forme et comment le mettre en place proprement. Il s’appuie sur la documentation de l’OWASP, du projet OWASP CRS, de Fortinet, de Cloudflare et de Microsoft.
Pourquoi le pare-feu réseau ne suffit pas pour un site web
Le pare-feu de l’entreprise décide qui peut joindre quel service. Pour un site public, une boutique ou un portail client, il doit laisser passer le trafic web vers le serveur : c’est sa raison d’être. Or c’est précisément dans ce trafic autorisé que se cachent les attaques applicatives. Une requête qui glisse une commande SQL dans un champ de recherche passe par le port 443, comme n’importe quel visiteur.
L’OWASP définit le WAF comme un pare-feu applicatif pour les applications HTTP : il applique un ensemble de règles à la conversation HTTP pour détecter les attaques courantes, comme le cross-site scripting et l’injection SQL. L’OWASP précise qu’un WAF protège les serveurs, et qu’on peut le considérer comme un proxy inverse.
Les applications concernées dans une entreprise sont souvent plus nombreuses qu’on ne le pense : site vitrine avec formulaire, boutique en ligne, extranet ou espace client, ERP ou CRM accessible depuis l’extérieur, API utilisée par une application mobile, portail de messagerie web.
Ce qu’un WAF bloque, et ce qu’il ne voit pas
| Le WAF est efficace contre | Le WAF voit mal |
|---|---|
| Injections (SQL, commandes, LDAP) | Un contrôle d’accès mal conçu dans l’application |
| Cross-site scripting (XSS) | Une logique métier détournable (remise, quantité, étape sautée) |
| Inclusion de fichiers, traversée de répertoires | Un compte légitime utilisé avec un mot de passe volé |
| Exploitation d’une faille publiée, avant la mise à jour | Une faille dans une bibliothèque côté navigateur |
| Robots agressifs, essais de connexion répétés | Une donnée sensible exposée par une mauvaise configuration |
Le classement OWASP Top 10 2025, référence des risques applicatifs, place en tête le contrôle d’accès défaillant (A01) et les erreurs de configuration (A02) ; l’injection arrive en A05. Un WAF agit surtout sur une partie de ces catégories. Le reste se traite dans l’application elle-même, par les mises à jour, la revue de configuration et les tests d’intrusion.
Le grand intérêt d’un WAF en exploitation est le correctif virtuel : quand une faille est publiée sur un logiciel exposé, une règle du WAF peut bloquer les tentatives d’exploitation en attendant la mise à jour. Microsoft le formule ainsi dans sa documentation : un WAF peut réagir plus vite en corrigeant de façon centralisée une vulnérabilité connue, au lieu de sécuriser chaque application. Cela donne du temps, sans dispenser de la gestion des correctifs, comme l’a rappelé notre alerte sur la faille PHP « PHP2Shell ».
Les trois formes de WAF
| Forme | Exemples | Adaptée à | Points d’attention |
|---|---|---|---|
| Service cloud devant le site | Cloudflare WAF, Azure WAF avec Azure Front Door ou Application Gateway | Site ou application hébergés chez un prestataire ou dans le cloud | Le trafic passe par le fournisseur ; il faut empêcher l’accès direct au serveur d’origine |
| Équipement ou machine virtuelle dédiée | FortiWeb, en matériel ou en machine virtuelle | Applications hébergées dans vos locaux, votre datacenter ou votre cloud privé | Exploitation, mises à jour des signatures, haute disponibilité |
| Module sur le serveur ou extension | ModSecurity ou Coraza avec l’OWASP CRS, extension de sécurité WordPress | Un serveur ou un site isolé | Consomme les ressources du serveur ; protection limitée à ce serveur |
Le WAF en service cloud
Le site reste chez son hébergeur, mais le nom de domaine pointe vers le service du fournisseur, qui filtre le trafic avant de le renvoyer au serveur. Selon la documentation de Cloudflare, son WAF combine des règles gérées mises à jour par l’éditeur, des règles personnalisées et des règles de limitation de débit ; l’offre gratuite inclut des règles personnalisées, une règle de limitation de débit et un jeu de règles gérées réduit, les règles gérées complètes étant réservées aux offres payantes. Chez Microsoft, Azure WAF se déploie avec Azure Front Door et Azure Application Gateway, et en préversion avec le réseau de diffusion de contenu Azure.
Point essentiel : si le serveur d’origine reste joignable directement par son adresse IP, un attaquant contourne le WAF. On limite donc l’accès au serveur aux seules adresses du fournisseur.
L’équipement ou la machine virtuelle dédiée
Pour une application hébergée chez vous, l’équipement WAF se place devant les serveurs web. La documentation de FortiWeb, le WAF de Fortinet, décrit plusieurs modes de fonctionnement : proxy inverse (mode par défaut, le trafic est adressé à un serveur virtuel du FortiWeb puis transmis au vrai serveur), modes transparents qui ne demandent pas de changement d’adresse ni de DNS, et protection hors ligne, passive, qui sert surtout à observer. FortiWeb ajoute des signatures FortiGuard, une détection d’anomalies et de robots par apprentissage automatique, la protection des API (JSON, XML, GraphQL, validation OpenAPI) et un tableau de bord de conformité à l’OWASP Top 10.
Sur un FortiGate, un profil de pare-feu applicatif web existe aussi, mais il ne fonctionne qu’avec l’inspection en mode proxy, d’après la documentation de FortiOS. Pour une application exposée importante, un WAF dédié reste plus complet.
Le module sur le serveur
ModSecurity et Coraza sont des moteurs WAF qui s’installent sur le serveur web. On les utilise avec l’OWASP CRS (Core Rule Set), un jeu de règles génériques de détection d’attaques qui couvre notamment l’injection SQL, le XSS, l’inclusion de fichiers et l’injection de commandes. Pour un site WordPress, une extension de sécurité apporte un filtrage du même type, comme nous l’expliquons dans notre guide pour sécuriser un site WordPress d’entreprise.
Quelle forme choisir selon votre situation
| Votre situation | Forme conseillée |
|---|---|
| Site vitrine WordPress chez un hébergeur | Service cloud devant le site, complété par une extension de sécurité |
| Boutique en ligne ou espace client hébergé dans le cloud | Service cloud avec règles gérées complètes, limitation de débit et journaux conservés |
| Application métier ou ERP hébergé dans vos locaux et ouvert à l’extérieur | Équipement ou machine virtuelle WAF devant les serveurs, en proxy inverse |
| Application hébergée sur Microsoft Azure | Azure WAF avec Application Gateway ou Front Door |
| API utilisée par une application mobile ou un partenaire | WAF qui valide le schéma de l’API (OpenAPI, JSON) et limite le débit |
Avant même de choisir, une question simple : l’application a-t-elle vraiment besoin d’être ouverte à tout Internet ? Un ERP utilisé seulement par les salariés peut souvent être réservé au VPN ou à un accès conditionnel, dans une logique zero trust. Ce qui n’est pas exposé n’a pas besoin d’être filtré. L’exposition compte aussi pour la conformité : un formulaire ou un espace client collecte des données personnelles, que la loi 09-08 impose de protéger par des mesures de sécurité adaptées.
Mettre un WAF en service sans casser le site
La principale difficulté d’un WAF n’est pas son installation, c’est son réglage. Un WAF trop sévère bloque des clients, un formulaire ou une synchronisation ; un WAF trop permissif ne sert à rien. La documentation de l’OWASP CRS décrit quatre niveaux de paranoïa : le niveau 1 déclenche très rarement de fausse alerte et constitue le point de départ recommandé ; chaque niveau supérieur détecte davantage d’attaques mais génère davantage de faux positifs. Elle juge très risqué de passer à un niveau élevé en mode blocage sans réglage préalable.
Notre méthode, dans l’ordre :
- Inventorier les applications exposées : adresses, technologies, formulaires, API, comptes d’administration.
- Démarrer en mode détection : le WAF journalise ce qu’il aurait bloqué, sans rien bloquer.
- Analyser les journaux sur une période d’usage normal, y compris les fins de mois et les traitements automatiques.
- Traiter les faux positifs par exclusions ciblées (une règle pour un paramètre ou une adresse précise), sans désactiver des familles entières de règles.
- Passer en mode blocage, d’abord sur les attaques les plus nettes, puis élargir.
- Verrouiller l’origine : seul le WAF peut joindre le serveur web.
- Surveiller : envoyer les alertes du WAF dans la supervision ou le SIEM, et revoir les règles à chaque évolution de l’application.
L’OWASP le rappelle : la personnalisation d’un WAF peut demander un effort important, et elle doit être entretenue à mesure que l’application change.
Les erreurs les plus fréquentes
- Laisser le WAF en mode détection pendant des mois sans regarder les journaux.
- Désactiver des règles entières au premier faux positif.
- Oublier de fermer l’accès direct au serveur d’origine.
- Croire que le WAF dispense des mises à jour de l’application et de son serveur.
- Protéger le site public mais oublier l’API, l’extranet ou l’accès d’administration.
- Laisser l’interface d’administration de l’application accessible à tout Internet, sans double authentification.
Comment nous accompagnons les entreprises
Nous commençons par l’audit initial offert : inventaire des sites et applications exposés, technologies et versions, protections en place, accès d’administration et journaux. Nous recommandons ensuite la forme de WAF adaptée, service cloud, équipement Fortinet ou service Microsoft Azure, puis nous le mettons en service en mode détection, réglons les faux positifs et passons au blocage. ALLSAFE fournit le matériel et les licences, avec ou sans installation.
Dans le cadre de notre offre de cybersécurité des entreprises au Maroc, les alertes du WAF remontent dans la supervision 24/7, et un incident critique est pris en charge en moins de 15 minutes. Demandez votre audit initial offert : nous vous répondons sous 24 h ouvrées.
Questions fréquentes
Quelle est la différence entre un pare-feu classique et un WAF ?
Le pare-feu réseau décide qui peut joindre quel service, par adresse, port et application ; il laisse passer le trafic web vers un site public, puisque ce site doit être accessible. Le WAF analyse le contenu de ces requêtes HTTP et HTTPS autorisées pour y repérer une attaque, par exemple une injection SQL dans un champ de formulaire. Les deux se complètent.
Un site vitrine a-t-il besoin d’un WAF ?
Un site vitrine bien entretenu, à jour et sans formulaire sensible peut se contenter d’un WAF en service cloud ou d’une extension de sécurité. Dès qu’il y a un espace client, une boutique, une API ou une application métier exposée sur Internet, un WAF configuré et surveillé devient une protection importante.
Un WAF protège-t-il contre toutes les failles ?
Non. Il bloque surtout les attaques reconnaissables dans la requête, comme les injections ou l’exploitation d’une faille connue. Il voit mal une erreur de contrôle d’accès propre à l’application, une logique métier mal conçue ou un mot de passe volé. Les mises à jour, la double authentification et les tests de sécurité restent indispensables.
Le WAF peut-il bloquer des clients légitimes ?
Oui, c’est le principal risque d’un WAF mal réglé : on parle de faux positifs. La documentation de l’OWASP CRS recommande de commencer au niveau de sensibilité le plus bas, de traiter les faux positifs par des exclusions ciblées et de n’augmenter la sévérité qu’après réglage. C’est pourquoi on démarre en mode détection.
Où placer le WAF : dans le cloud ou dans nos locaux ?
Cela dépend de l’emplacement de l’application. Pour un site hébergé chez un prestataire ou dans le cloud, un WAF en service cloud placé devant le site est le plus simple. Pour une application hébergée dans vos locaux ou dans votre datacenter, un équipement dédié ou une machine virtuelle WAF placée devant les serveurs garde le trafic sous votre contrôle.
À propos de la rédaction
ALLSAFE SOLUTIONS
Ingénieurs réseau, sécurité et cloud
Rédigé par l’équipe d’ingénieurs d’ALLSAFE SOLUTIONS, infogérant fondé à Casablanca par des ingénieurs réseau, sécurité et cloud. Nos articles s’appuient sur les projets que nous menons chez nos clients, au Maroc comme à l’international.
LinkedIn
