Le Web Application Firewall (WAF) est un de ces outils dont on parle souvent, mais qu’on exploite rarement à son plein potentiel. Dans bien des cas, il est installé hâtivement, activé avec des règles par défaut, puis laissé en place comme un simple bouclier passif.
Ce billet de blog a pour objectif d’expliquer comment tirer le meilleur parti d’un WAF : comprendre ce qu’il fait réellement, estimer son coût global, éviter les erreurs courantes et, surtout, construire une approche mesurable de son efficacité.
Pourquoi et quand utiliser un WAF ?
Un WAF devient indispensable dès qu’une application web manipule des données sensibles (compte client, paiement, santé), expose des API critiques (mobile, partenaires, back-office), est soumise à des exigences de conformité (PCI-DSS, RGPD) ou subit des attaques récurrentes (credential stuffing, bots, scans agressifs). Ses usages typiques incluent :
la réduction d’exposition face aux vulnérabilités du Top 10 OWASP (injections, XSS, RCE),
le virtual patching pour atténuer un zero-day ou un correctif applicatif en attente,
la défense contre les bots (scraping, prise de contrôle de comptes, volumétrie anormale sur les endpoints sensibles).
À l’inverse, sur un site purement statique servi par un CDN, un WAF apporte peu de valeur et peut même ajouter de la latence si mal configuré. Le contexte doit donc dicter son usage : valeur métier des endpoints, sensibilité des données, exposition aux tiers et maturité de l’équipe.
Les sections qui suivent répondent aux trois enjeux clés : bien placer le WAF dans l’infrastructure, choisir une solution adaptée au coût et aux besoins, et adopter une démarche active plutôt que “tout bloquer par défaut”.
Qu’est-ce qu’un WAF ?
Techniquement, un Web Application Firewall est un composant agissant sur la couche 7 du modèle OSI (soit la couche applicative), il intercepte le trafic HTTP(S) et décide, pour chaque requête, s’il faut :
l’autoriser,
la bloquer,
la défier (CAPTCHA, challenge JavaScript),
ou la marquer pour inspection (état “Counted” sur AWS).
Les moteurs modernes combinent plusieurs signaux :
Signatures classiques (patterns d’injections SQL, XSS, etc.),
Heuristiques et comportement (taux de requêtes, anomalies dans les headers, payloads atypiques),
Réputation (IP connues pour scanner ou attaquer, Tor, proxys, etc.),
Contexte (pays, autonomous system (AS), User-Agent, cookie, session).
Un WAF efficace n’est pas seulement un moteur de règles, l’équipe en charge de cette brique de sécurité doit être capable de :
Reconnaître une réelle tentative d’attaque par un acteur malveillant au milieu du bruit des scans automatiques,
Prendre des actions défensives en fonction de la tendance du trafic sur l’application,
Faire évoluer en continu la politique de filtrage à partir des retours d’expérience et des faux positifs détectés en production.
Où le positionner dans l’infrastructure ?
C’est surtout ici qu’il est possible de ruiner l’efficacité d’un WAF. L’emplacement du WAF dans votre architecture détermine à la fois sa performance et son efficacité.
Option 1 : WAF sur le CDN
Dans certains projets, le WAF est simplement greffé sur la couche CDN (exemple AWS ci-dessous) :
C’est pratique et rapide, mais c’est une fausse bonne idée :
Les règles sont appliquées sur tout le trafic CDN, y compris les assets statiques,
Certaines règles (inspection profonde, regex lourdes) peuvent réduire, parfois complètement, l’efficacité du cache,
Les vraies attaques intéressantes visent rarement /assets/smile.webp, mais plutôt les endpoints d’API.
Néanmoins, cette architecture peut avoir du sens dans les cas suivants :
pour des sites publics très volumétriques,
pour une première couche de filtrage large (geo-IP, réputation, DDoS L7 simple, geo-blocking).
C’est en revanche une mauvaise idée :
quand toute la logique métier est derrière une API distincte, exposée sur un autre domaine / endpoint,
quand des règles très fines (OWASP, vérifications au niveau du payload d’une requête) doivent être appliquées directement au niveau CDN.
Option 2 : WAF au niveau du load balancer
Autre possibilité, plus courante : accrocher le WAF au niveau du load balancer, juste avant l’origin applicatif :
Dans ce cas-là, on conserve la pleine efficacité du WAF, tout en laissant au CDN son rôle naturel : il continue d’assurer le cache des assets statiques, la minification du bundle JS et les autres transformations en périphérie.
La passerelle de filtrage est placée au plus près du serveur qui est derrière le WAF, là où passent :
les requêtes authentifiées,
les mutations de données,
les parcours critiques (login, paiements, administration).
Ce placement apporte deux bénéfices majeurs :
Le coût reste concentré sur l’analyse du trafic réellement applicatif, puisque seules les requêtes qui atteignent l’origin passent par le WAF plutôt que tout le flux CDN.
Les règles peuvent être adaptées finement par listener ou par chemin, ce qui permet d’appliquer des politiques spécifiques aux API internes, aux parcours sensibles ou aux interfaces back-office sans perturber le reste du site.
Option 3 : WAF au niveau de l’API Gateway
Enfin, dans les architectures très API / micro-services, le WAF est souvent intégré directement sur la gateway :
Cette organisation prend tout son sens lorsque :
l’essentiel du trafic est JSON / REST / SOQP / gRPC,
l’objectif est de centraliser les contrôles sur les chemins d’API (méthodes autoridées, DTO, quotas, etc.).
La protection devient alors une combinaison :
de règles WAF, qui filtrent et bloquent les requêtes malveillantes (injections, XSS, bots, etc.) au niveau du trafic HTTP(S)
de politiques d’API, qui encadrent l’usage fonctionnel des endpoints (quotas, rate limiting, validation de schémas, transformation de payload, gestion d’erreurs)
de contrôle d’accès, qui garantit que seules les identités autorisées peuvent appeler les API sensibles (authentification, autorisation fine, scopes, rôles)
Éliminer les chemins de contournement
Une protection HTTP ne sert à rien si l’attaquant peut atteindre directement le serveur protégé par le WAF.
Pour éviter que ce soit possible il y a plusieurs solutions :
L’origin est dans un réseau privé (subnet non routable depuis Internet),
Seul le CDN / WAF peut y accéder :
via des CIDR d’IP source restreintes,
ou vie des mécanismes d’origine privée (PrivateLink, VPC endpoint, etc.),
Les firewalls / security groups sont configurés pour rejeter tout autre trafic.
Pour éviter cela, une pratique courante sur AWS consiste à:
ALB en subnet public mais :
Security Group autorisant uniquement les IP source de CloudFront,
Éventuellement une IP fixe de bastion d’admin
Origin type EC2/ECS/Fargate en subnet privé, accessible uniquement depuis l’ALB.
Il est aussi possible de rajouter un header “secret” entre le CDN et l’origin avec un shared secret comme valeur, et refuser toute requête qui ne le contient pas, c’est utile pour limiter les scénarios de host header poisoning (lorsqu’un attaquant forge le header Host pour viser une autre application derrière le reverse proxy, empêcher le cache de fonctionner correctement, …), en revanche, cela complexifie la configuration.
Combien coûte un WAF ?
Un déploiement via un cloud provider (AWS, GCP, …) implique une facturation à la requête (avec un tarif dégressif en fonction du volume de requêtes), tandis qu’un déploiement on-premise repose plutôt sur une licence à coût fixe et un investissement initial plus important.
Dans les deux cas, il faut raisonner en TCO (Total Cost of Ownership), en intégrant la bande passante, la maintenance, la gouvernance et les coûts cachés d’une mauvaise configuration (comme les faux positifs, la latence ou la surchage des logs).
WAF Cloud
Les offres cloud-native (AWS WAF, Azure Front Door, Google Cloud Armor, etc.) reposent sur des modèles de facturation à la requête. On paie généralement selon :
le nombre de requêtes traitées (facturation par paliers de millions de requêtes mensuellement),
le volume de règles actives ou de modules avancés (bot management, IP reputation, rate liming, etc.),
le trafic sortant (bande passante) et parfois le nombre de distributions (ou domaines protégés).
Ces solutions présentent l’avantage d’une maintenance minimale et d’une intégration directe aux services du cloud provider, mais leur coût peut croître rapidement si le trafic est important ou si les règles sont mal optimisées. Elles conviennent particulièrement aux architectures élastiques où la charge varie fortement.
WAF on-premise
Les solutions on-premise reposent plutôt sur un modèle de licence fixe, souvent indexé sur :
le débit maximal autorisé,
le nombre d’instances ou de noeuds,
parfois des modules additionnels (analytics, monitoring des ressources, etc.).
Elles impliquent un investissement initial plus élevé mais permettent une maîtrise complète du trafic, des logs et de la personnalisation des règles. En revanche, elles demandent plus de ressources humaines pour l’exploitation et les mises à jour de sécurité.
ModSecurity reste l’option open source de référence, intégrable avec NGINX ou Apache, et sert souvent de base à un déploiement WAF on-premise.
Comment maximiser l’efficacité d’un WAF ?
L’optimisation d’un WAF s’inscrit dans une démarche d’amélioration continue. Il ne s’agit pas seulement d’installer un produit, mais de construire une stratégie de défense.
Phase d’apprentissage
Il est recommandé de commencer systématiquement en mode observation ("count" sur AWS, "log only" ailleurs). L’objectif n’est pas encore de bloquer, mais de tracer toutes les requêtes suspectes et de qualifier leur nature.
On exporte les logs vers une solution de Security Information and Event Management (SIEM) ou un data lake, on étiquette les patterns récurrents (scans automatisés, outils d’audit interne, tentatives réelles d’exploitation) et on construit des baselines : volume par endpoint, répartition des méthodes, headers usuels. Cette photographie sert de référence pour les phases suivantes.
Durcissement progressif
Une fois la normalité connue, on active des politiques positives sur les parcours critiques (authentification, paiements, administration). Concrètement, on décrit les "input contracts" autorisés : méthodes HTTP admises, schémas JSON attendus, jeux de headers tolérés, plages d’IP connues ou empreintes d’app clients.
Tout ce qui sort de ce périmètre est bloqué ou challengé. On procède API par API pour limiter les faux positifs, on alimente un plan d’intervention qui précise quelles actions entreprendre en cas d’alerte (désactivation temporaire, création d’une règle d’exception, escalade vers l’équipe produit).
Automatisation et gouvernance
Le WAF devient pérenne lorsqu’il est géré comme du code. Les règles sont décrites dans un dépôt IaC (comme Terraform), les modifications passent par revue de code, et des tests automatisés (ex. terraform plan, suites de requêtes curl ou k6 reproduisant les cas critiques) valident qu’un changement ne casse pas un parcours légitime.
On versionne aussi les dictionnaires de signatures maison, on tague chaque règle avec un ticket ou un incident pour conserver la traçabilité, et on documente les dépendances (API affectées, équipes propriétaires) pour pouvoir les notifier en cas de modification.
Suivi des KPI
Pour suivre le durcissement des règles, ces KPI sont les plus pertinents :
Taux de faux positifs (objectif <0,1%) : compare règles déclenchées et incidents réels.
Ratio observé vs bloqué : mesure la part de règles encore en détection et le passage progressif vers le blocage.
Latence ajoutée (cible <30 ms P95) : surveille le coût de performance du WAF.
Couverture fonctionnelle : pourcentage d’API protégées par une politique positive.
En complément, on mesure le temps moyen de réaction pour créer une règle suite à un incident et le temps moyen pour supprimer ou assouplir une règle devenue inutile, afin de garantir que le dispositif reste agile.
Accompagnement Galadrim
Chez Galadrim, nous opérons déjà des WAF en production pour différents secteurs : e-commerce soumis à de fortes variations de charge, fintech régulées, éditeurs SaaS qui exposent des API critiques, acteurs du domaine de la santé, etc.
Notre équipe MSSP conçoit les politiques positives, implémente l’IaC, surveille les KPI et intervient lors des incidents.
Conclusion
Un WAF n’est pas infaillible : il ne peut ni corriger une application vulnérable, ni se substituer à de bonnes pratiques de développement. En revanche, c’est un outil précieux pour mieux maîtriser le trafic et mieux comprendre les incidents. Bien configuré, il aide à détecter plus tôt les comportements anormaux, à réduire l’impact d’une attaque et à maintenir la disponibilité des services.
Sa valeur se révèle pleinement lorsqu’il est couplé à une hygiène applicative solide : une surface d’attaque réduite, des correctifs appliqués rapidement et une gestion rigoureuse des identités et des accès. Dans ce cadre, le WAF devient un allié de la résilience opérationnelle, un moyen d’absorber l’imprévisible tout en conservant la maîtrise de son exposition au risque.
Pour finir, gardez en tête ces erreurs à éviter :
Placer le WAF avant le CDN : cela annule les bénéfices du cache et augmente la latence.
Laisser l’origin accessible : l’application doit uniquement être atteignable via le CDN ou le WAF. Tout accès direct peut constituer une faille.
Activer le blocage sans période d’observation : il est impératif de commencer en mode détection, le temps d’ajuster les règles et d’éliminer les faux positifs.
Configurer manuellement : sans IaC, les dérives de configuration s’accumulent et la traçabilité disparaît.
