Vous avez une application web sur un VPS. Le journal d'accès montre des tentatives de connexion sur /wp-admin, des requêtes contenant UNION SELECT dans la chaîne de requête et un trafic constant provenant de plages d'IP de datacenters qui n'ont rien à faire sur votre site. Vous voulez filtrer les déchets évidents avant qu'ils n'atteignent votre application.
C'est à ce moment que la plupart des gens découvrent le terme WAF SaaS. Pour beaucoup de lecteurs, « le WAF » et « Cloudflare » sont la même chose, parce que Cloudflare est ce qu'ils ont croisé en premier. Ce n'est pas la même chose. Le WAF SaaS est une catégorie : un pare-feu applicatif web livré depuis le cloud, qui inspecte votre trafic HTTP à la périphérie du fournisseur avant de le transmettre à votre origine. Cloudflare est un produit parmi d'autres dans cette catégorie.
Cet article explique comment fonctionne le WAF SaaS, ce que facturent les principaux fournisseurs, où il échoue en pratique, et quand faire tourner votre propre WAF sur un VPS Linux est la meilleure option.
En bref
- Le WAF SaaS est un pare-feu applicatif web livré depuis le cloud. Vous faites transiter le trafic par le fournisseur ou vous associez le WAF à une ressource cloud prise en charge ; le service évalue les requêtes HTTP(S) avant que l'application protégée ne les traite.
- Les grands fournisseurs utilisent trois grandes formes de tarification : les paliers d'abonnement (Cloudflare et Sucuri), la facturation à l'usage (AWS WAF) et les devis commerciaux (Imperva et Fastly). Les coûts à l'usage augmentent avec les requêtes traitées et les options activées, alors que les formules d'abonnement sont en général plus prévisibles.
- Il existe une critique documentée du WAF SaaS, et elle est abordée plus bas. Elle pointe la latence, les faux positifs, les blocages opaques et le routage des données vers un tiers.
- Les WAF auto-hébergés sur un VPS sont une vraie option. SafeLine et BunkerWeb sont les deux projets open source qui ont le vent en poupe. Ils fonctionnent comme un reverse proxy devant votre application.
- Ne pas avoir de WAF du tout peut être un choix défendable quand la sécurité applicative est mature, l'exposition maîtrisée, la supervision solide et le risque résiduel documenté et accepté.
Comment fonctionne le WAF SaaS
Une requête vers example.com atteint d'abord l'edge du fournisseur, parce que votre DNS pointe vers lui. Le nœud de périphérie termine le TLS, analyse la requête HTTP, la fait passer par un moteur de règles, puis la transmet à votre origine, la bloque, la challenge (CAPTCHA, test JavaScript) ou limite le débit de la source. S'il la transmet, votre application voit la requête comme si elle venait de l'IP du fournisseur, l'IP client d'origine étant passée dans un en-tête du type X-Forwarded-For ou CF-Connecting-IP.
Beaucoup de produits WAF SaaS utilisent un reverse proxy managé par le fournisseur ou une intégration en périphérie, mais tous les services ne se déploient pas par un changement DNS. Cloudflare, Sucuri et Fastly se placent couramment dans le chemin de la requête, en périphérie. AWS WAF, lui, s'associe à CloudFront ou à des ressources AWS prises en charge telles que les Application Load Balancers, les API d'API Gateway et les API AppSync. Dans tous les cas, les requêtes HTTP(S) sont évaluées avant que l'application protégée ne les traite.
Un WAF inspecte les données de couche 7 : en-têtes de requête, chemins, chaînes de requête, méthodes, cookies et la portion configurée des corps de requête. Un pare-feu réseau classique décide surtout aux couches 3 et 4, à partir des adresses, des protocoles et des ports. Notre guide pare-feu matériel ou logiciel couvre cette distinction plus large.
La protection WAF managée puise en général dans trois sources de règles :
- L'OWASP Core Rule Set (CRS) est une base open source pour ModSecurity et les moteurs WAF compatibles. Elle couvre les grandes catégories d'attaques : injection SQL, cross-site scripting, injection de commandes et inclusion de fichiers locaux. Les produits bâtis autour de ModSecurity embarquent souvent CRS, tandis que beaucoup de fournisseurs cloud utilisent plutôt leurs propres règles managées.
- Les jeux de règles managés par l'éditeur sont des règles propriétaires que le fournisseur tient à jour. Les « Managed Rules » de Cloudflare, les « AWS Managed Rules » d'AWS WAF et le flux de renseignement sur les menaces d'Imperva entrent dans cette catégorie.
- Les règles personnalisées sont celles que vous écrivez vous-même. « Bloquer les requêtes vers /admin qui ne viennent pas de cette plage d'IP », « limiter /api/login à 5 requêtes par minute et par IP ».
Une règle anti-injection SQL peut repérer un motif familier comme ' OR 1=1 -- dans un paramètre de requête ou dans le corps de la requête. Cela attrape les sondes paresseuses, mais un WAF peut toujours rater des charges utiles obfusquées, des failles de logique et des requêtes malveillantes qui ressemblent à du trafic applicatif normal. Il évalue des signaux observables de la requête, pas une intention métier.
Ce contre quoi il protège, en clair :
- Les attaques par injection dont la charge utile correspond à une signature connue
- Le trafic de bots issu de scanners connus
- Les schémas simples de force brute
- Le DDoS volumétrique, quand le fournisseur assure aussi le nettoyage DDoS
- Les abus d'API basiques
Ce qu'il ne fait pas :
- Corriger votre application
- Remplacer la validation des entrées dans votre code
- Arrêter les attaques qui ressemblent à du trafic normal
La sécurité applicative vient toujours de l'application. Un WAF relève le plancher face aux attaques courantes et automatisées, mais ce sont le code sécurisé, les correctifs, l'autorisation, le traitement des entrées, la supervision et la réponse à incident qui fixent le plafond.
WAF SaaS, appliance sur site ou auto-hébergement sur un VPS
Il existe trois modèles de déploiement WAF courants en 2026 : le WAF SaaS cloud (Cloudflare, AWS WAF, Fastly et d'autres), les appliances physiques ou virtuelles (dont les offres F5 et Imperva), et le logiciel auto-hébergé sur un VPS ou sur votre propre serveur.
Les trois diffèrent sur quatre questions pratiques : qui exploite le plan d'inspection, qui paie la capacité, qui règle les règles, et que se passe-t-il quand le WAF bloque quelque chose qu'il n'aurait pas dû bloquer. Le reste de l'article utilise ces quatre questions comme grille de comparaison.
WAF SaaS cloud
Vous faites transiter le trafic par l'edge du fournisseur ou vous associez le WAF à une ressource cloud prise en charge. Le fournisseur exploite la capacité d'inspection et les mises à jour managées, tandis que vous choisissez les règles, créez des politiques propres à l'application et réglez les exceptions. Parmi les options courantes : Cloudflare, AWS WAF, Imperva, Sucuri et Fastly.
Le compromis : la capacité et l'exploitation sont le problème de quelqu'un d'autre. Mais chaque requête HTTP transite aussi par l'infrastructure de quelqu'un d'autre. Votre trafic HTTP passe par l'infrastructure du fournisseur, et les métadonnées de requête ou les extraits de charge utile détectés peuvent être journalisés selon le fournisseur, le produit et les réglages de journalisation.
WAF en appliance sur site
Une appliance physique ou virtuelle se place sur le chemin de votre réseau. Les acheteurs sont typiquement des organisations avec des opérations de sécurité réseau établies, des besoins de capacité fixes, des contrôles de déploiement stricts ou des relations fournisseurs existantes. La capacité, les mises à niveau, la haute disponibilité et le réglage restent à la charge du client.
Pour beaucoup d'équipes petites et moyennes, l'achat d'appliance, la capacité figée et la charge d'exploitation en font la voie la moins praticable. Elle peut malgré tout convenir aux organisations qui ont besoin d'un plan de contrôle dans le réseau et du personnel pour l'exploiter.
WAF auto-hébergé sur votre propre VPS
Vous installez un WAF sur un VPS Linux, vous pointez votre DNS vers ce VPS, et le WAF se place en reverse proxy devant votre application. C'est vous qui l'exploitez. C'est vous qui le réglez. C'est vous qui vous connectez à 2 h du matin quand une mise à jour de règle managée bloque une requête légitime et qu'il n'y a personne d'autre à appeler.
Deux projets open source ont le vent en poupe : SafeLine, un WAF open source qui s'appuie sur un moteur d'analyse sémantique plutôt que sur de la correspondance par expressions régulières, et BunkerWeb, un WAF basé sur NGINX qui embarque ModSecurity. Leurs licences, modèles de déploiement et empreintes en ressources sont détaillés plus loin, dans la section auto-hébergement.
Le compromis est l'inverse du modèle SaaS. Vous contrôlez le plan d'inspection, la capacité, les journaux et le réglage. Cela réduit la dépendance à un fournisseur WAF tiers, mais les réseaux en amont et les hébergeurs transportent toujours le trafic. Les limites d'infrastructure, la bande passante, les correctifs et la réponse à incident sont désormais votre responsabilité.
WAF SaaS ou WAF auto-hébergé sur votre VPS
Le tableau comparatif ci-dessous se concentre sur les différences pratiques que les administrateurs système doivent exploiter et budgéter.
| Critère | WAF SaaS cloud | WAF auto-hébergé sur un VPS |
|---|---|---|
| Qui exploite le plan d'inspection | Le fournisseur, en périphérie du réseau | Vous, sur votre VPS |
| Qui paie la capacité | Le fournisseur, refacturé sur abonnement ou à la requête | Vous, coût fixe du VPS |
| Qui règle les règles | Vous configurez ; le fournisseur livre les mises à jour de règles managées | Vous, de bout en bout |
| Recours en cas de faux positif | Régler les règles et les exceptions dans les limites des contrôles du fournisseur ; escalader les problèmes de plateforme | Modifier la règle vous-même ; redéployer en quelques minutes |
| Acheminement des données | Les requêtes passent par l'infrastructure d'inspection du fournisseur | Les requêtes passent par une infrastructure que vous contrôlez avant d'atteindre l'origine |
| Comportement du coût pendant un pic de trafic | Les composants facturés à l'usage peuvent augmenter avec le volume de requêtes | Généralement plus prévisible, mais la bande passante et la montée en charge peuvent quand même coûter |
| Charge opérationnelle | Faible, limitée à la configuration et au réglage | Vous exploitez le VPS et le WAF |
Les tarifs du WAF SaaS en 2026
La tarification du WAF SaaS combine en général des paliers d'abonnement, des frais à l'usage ou des devis commerciaux. Les prix publics ne sont pas directement comparables, parce que chaque fournisseur emballe différemment les règles managées, le contrôle des bots, la journalisation, le support et les fonctions anti-DDoS.
| Fournisseur | Modèle tarifaire | Prix d'entrée | Ce que comprend l'offre d'entrée | Remarques |
|---|---|---|---|---|
| Cloudflare | Palier d'abonnement | Gratuit ; Pro 20 $/mois en annuel ou 25 $/mois en mensuel ; Business 200 $/mois en annuel ou 250 $/mois en mensuel | Free Managed Ruleset ; les contrôles plus larges varient selon l'offre payante | Vérifiez les règles, les limites et les fonctions de sécurité incluses au moment de l'achat |
| AWS WAF | À la requête | $5 per web ACL/month plus $1 per rule or rule group/month plus $0.60 per million requests | Règles que vous gérez vous-même ; les AWS Managed Rules peuvent être ajoutées en tant que groupes de règles managés | Capacité supplémentaire, inspection du corps, groupes managés premium, CAPTCHA, Challenge, Bot Control et Fraud Control peuvent ajouter des frais |
| Imperva | Devis entreprise | Contacter l'équipe commerciale | Règles managées, renseignement sur les menaces et options de sécurité des API | Pas de prix WAF en libre-service publiquement comparable |
| Sucuri Platform | Palier d'abonnement | Basic Firewall à 9,99 $/mois ; Basic Platform à 229 $/an | Offre firewall : WAF/CDN ; le bundle Platform ajoute l'analyse et le nettoyage | Le pare-feu autonome et le bundle Platform annuel sont deux produits différents |
| Fastly | Via l'équipe commerciale | Contacter l'équipe commerciale | Inspection en périphérie ou distribuée, règles managées et protection des API | Pas de prix WAF en libre-service publiquement comparable |
AWS WAF publie le prix de chaque composant, tandis que Cloudflare et Sucuri publient des tarifs d'offres en libre-service. Imperva et Fastly passent par une tarification commerciale pour des offres WAF comparables.
Vérification effectuée le 29 juillet 2026 : la page des offres Cloudflare indique Pro à 20 $ par mois en facturation annuelle ou 25 $ en mensuelle, et Business à 200 $ par mois en annuelle ou 250 $ en mensuelle. La page tarifaire du pare-feu Sucuri lists Basic Firewall at $9.99 per month and Basic Platform at $229 per year. The firewall and platform bundles are different products. The AWS WAF figures above come from la tarification d'AWS WAF as of the same date.
Imperva et Fastly ne publient pas de prix WAF en libre-service directement comparables : traitez-les donc comme des options « contactez le service commercial » plutôt que de vous fier à des estimations tierces.
La page tarifaire d'AWS WAF indique des frais de base de 5 $ par web ACL et par mois, 1 $ par règle ou groupe de règles et par mois, et 0,60 $ par million de requêtes traitées. Des frais supplémentaires peuvent s'appliquer pour la capacité additionnelle, une inspection de corps plus large, les actions CAPTCHA ou Challenge, les groupes managés premium et les contrôles anti-fraude ou anti-bots. Le trafic d'attaque peut donc faire monter la facture, mais l'ampleur dépend du volume, de la durée et des fonctions activées. Les règles basées sur le débit protègent l'application ; elles ne rendent pas gratuites les requêtes WAF déjà traitées.
Là où le WAF SaaS montre ses limites
Les faux positifs sont la première limite pratique. Un envoi de fichier légitime, un appel d'API ou une soumission de formulaire peuvent ressembler à un motif d'attaque et déclencher une règle managée. L'exploitant doit alors identifier la règle concernée, la restreindre ou l'exclure, et vérifier que l'exception ne crée pas un contournement plus large.
Les WAF décident à partir de signaux de requête, pas d'une intention métier. Des règles strictes peuvent bloquer du trafic légitime ; des exceptions trop larges peuvent affaiblir la protection. Les services cloud fournissent en général des journaux d'événements, des surcharges de règles et des réponses personnalisées, mais la visibilité et les leviers de réglage disponibles varient selon l'offre et le fournisseur.
Astuce de pro. Démarrez les règles nouvelles ou fortement modifiées en mode détection ou comptage. Observez un trafic représentatif, testez les parcours critiques et les parcours rares, passez les faux positifs en revue et ajoutez des exclusions étroitement ciblées avant d'activer le blocage. Les recommandations actuelles de réglage de CRS recommandent une à deux semaines, ou jusqu'à ce que le trafic de pointe et les parcours critiques aient été exercés.
La deuxième limite est le surcoût de performance. Un test de performance ModSecurity de 2023 a mesuré 9 462 envois de petits fichiers en 7,36 secondes avec CRS activé, contre 4,55 secondes sans. Le débit est tombé de 2 079 à 1 285 requêtes par seconde, tandis que le pic de CPU nginx passait de 8 % à 73 %. Il s'agissait d'une seule configuration et d'une seule charge de travail : prenez ce résultat comme la preuve que l'inspection a un coût, pas comme un ratio de dimensionnement universel.
La troisième limite est l'acheminement des données. Chaque requête HTTP, corps compris, passe par l'infrastructure du fournisseur. Pour les applications qui manipulent des données personnelles, des transactions financières ou des données de santé, c'est une question concrète de souveraineté des données. Une application hébergée dans l'UE qui fait transiter les requêtes de ses clients par un fournisseur WAF américain a une piste d'audit plus lourde à justifier, et quelques clauses contractuelles de plus à signer, que la même application avec un reverse proxy auto-hébergé sur un VPS dans la même juridiction.
La quatrième limite est la charge de réglage. Les difficultés de réglage d'un WAF comprennent les faux positifs, un contexte applicatif limité et des règles qui doivent suivre le rythme de changements de code fréquents. La source est celle d'un éditeur, mais le schéma opérationnel est réel : soit les équipes investissent dans un réglage continu, soit elles laissent davantage de règles en mode détection seule.
La même critique de 2023 soutient que les WAF peuvent devenir du théâtre de sécurité quand les équipes s'appuient dessus au lieu de corriger l'application. Cet argument est le plus fort pour les équipes dont la sécurité applicative est mûre : accès paramétré à la base de données, autorisation solide, analyse régulière des dépendances, déploiements immuables et supervision efficace. Dans des environnements moins mûrs, un WAF peut malgré tout réduire l'exposition aux sondages automatisés courants. Les deux affirmations peuvent être vraies.
Les WAF sont une couche parmi d'autres dans une défense en profondeur. Ils ne remplacent pas la sécurité applicative, et ils ne sont pas non plus du théâtre de sécurité. La valeur marginale d'un WAF est élevée pour certaines équipes et faible pour d'autres. Ce qui tranche, c'est l'état de l'application en dessous.
Quand l'auto-hébergement d'un WAF a du sens
L'auto-hébergement l'emporte dans trois situations. Il perd dans trois autres. Commençons par les cas où il l'emporte.
L'auto-hébergement l'emporte quand des contraintes de politique interne ou de souveraineté des données excluent l'inspection par un intermédiaire WAF SaaS externe, quand les profils de trafic rendent la tarification à l'usage moins intéressante que de faire tourner une infrastructure dédiée, et quand une équipe veut un contrôle direct sur les décisions de blocage et sur la correction des faux positifs.
L'auto-hébergement perd quand il n'y a pas de capacité opérationnelle, quand l'application tourne sur une plateforme managée dont le modèle de routage rend un proxy externe malcommode, ou quand une offre gratuite managée par un fournisseur couvre déjà les contrôles nécessaires avec moins de complexité.
L'offre gratuite de Cloudflare peut être un point de départ pratique pour des équipes petites et moyennes qui utilisent déjà son DNS ou son CDN et acceptent son modèle d'inspection du trafic. L'auto-hébergement devient plus intéressant quand l'acheminement des données, le contrôle direct des règles ou la prévisibilité des coûts d'infrastructure comptent plus que réduire l'exploitation au minimum.
SafeLine et BunkerWeb
Deux WAF open source auto-hébergés méritent d'être connus.
SafeLine est publié sous licence GPL-3.0, se déploie avec Docker Compose et repose sur une analyse sémantique plutôt que sur un jeu de règles CRS pur. Le dépôt SafeLine annonce 71,65 % de détection, 0,07 % de faux positifs et 99,45 % de précision globale en mode Balance, sur sa propre évaluation de 33 669 échantillons. Ce sont des mesures faites par les mainteneurs du projet, pas un test indépendant, et elles ne doivent pas être généralisées au-delà de ce jeu de test.
BunkerWeb est publié sous licence AGPL-3.0 et utilise NGINX sous le capot. Il intègre ModSecurity avec l'OWASP Core Rule Set et prend en charge plusieurs modes de déploiement, dont Linux, Docker, Swarm et Kubernetes.
Dimensionnez l'un ou l'autre à partir d'un volume de requêtes mesuré, des protections activées, du travail TLS et de la rétention des journaux. Pour un déploiement SafeLine à faible trafic, 2 vCPU et 4 Go de RAM sont un point de départ prudent, avec de la marge au-dessus du minimum d'installation. Les recommandations actuelles du guide de démarrage BunkerWeb recommandent au moins 2 vCPU et 8 Go de RAM pour des tests ou très peu de services, et 4 vCPU avec 16 Go de RAM pour des environnements de production protégeant de nombreux services. Le stockage dépend surtout du débit de journaux et de la durée de rétention : mesurez-le plutôt que de promettre un nombre de mois fixe.
Astuce de pro. Faites tourner le WAF auto-hébergé dans la même région que l'origine de l'application chaque fois que c'est possible. Un proxy distant ajoute un aller-retour réseau interrégional à chaque requête et peut dégrader la latence sans bruit. Mesurez le temps de réponse de bout en bout depuis les régions de vos utilisateurs avant la bascule en production.
C'est vous qui exploitez le WAF, ce qui veut dire que l'infrastructure sous-jacente est aussi votre responsabilité : disponibilité, correctifs de sécurité, certificats TLS, sauvegardes, rotation des journaux, supervision, capacité et reprise. Testez le comportement en cas de panne avec autant de soin que les règles de filtrage, pour que le WAF ne devienne pas un point de défaillance unique.
Un cadre de décision
Quatre voies existent : l'offre gratuite de Cloudflare, un WAF SaaS cloud payant, un WAF auto-hébergé sur un VPS, et pas de WAF du tout. La condition qui désigne chacune est différente.
Choisissez une offre WAF cloud gratuite quand les règles managées et les limites disponibles correspondent au risque de l'application, que le modèle d'acheminement des données est acceptable et que minimiser le travail d'exploitation est la priorité. Testez de vrais parcours utilisateur avant de supposer que les réglages par défaut suffisent.
Choisissez un WAF SaaS payant quand vous avez besoin de plus de règles managées, de journalisation, de contrôles personnalisés, de protection des bots ou des API, de support ou de capacité que ce que l'offre gratuite fournit. Comparez la matrice exacte des fonctions et des limites, pas seulement le nom du plan. AWS WAF est le plus pertinent quand l'application utilise déjà des ressources AWS prises en charge et que l'équipe est à l'aise pour prévoir des frais par composant.
Choisissez un WAF auto-hébergé quand les conditions d'auto-hébergement citées plus haut s'appliquent et que votre équipe sait exploiter le proxy de façon fiable. SafeLine et BunkerWeb sont les deux projets à évaluer en premier.
Ne pas avoir de WAF du tout peut être un choix défendable quand la sécurité applicative est mature, l'exposition délibérément maîtrisée, la supervision solide et le risque résiduel documenté et accepté. Cela ne doit pas devenir le choix par défaut au seul motif qu'un framework valide les entrées.
Conclusion
Choisissez le WAF SaaS pour une capacité gérée par le fournisseur et moins de charge d'exploitation. Choisissez l'auto-hébergement pour un contrôle direct, quand l'équipe sait faire tourner le proxy de façon fiable. Dans les deux cas, déployez les règles par étapes, mesurez la latence et les faux positifs, et gardez la sécurité applicative au premier plan.
Si l'auto-hébergement correspond à vos besoins, commencez avec un Linux VPS dans la même région que l'origine. Cloudzy propose aussi des déploiements marketplace en un clic pour SafeLine et pour BunkerWeb, pour que vous puissiez commencer à tester sans monter la pile de base à la main.
Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.
Voir les plans LinuxFoire aux questions
Qu'est-ce que le WAF as a service ?
Le WAF as a service est un pare-feu applicatif web livré depuis le cloud. Le trafic atteint le service via un routage DNS ou reverse proxy, via une intégration en périphérie, ou par association à une ressource cloud prise en charge. Le fournisseur exploite la capacité d'inspection et les mises à jour managées ; vous choisissez les politiques, réglez les exceptions et ajoutez des règles propres à l'application.
Cloudflare est-il un WAF ?
Oui. Cloudflare fournit des fonctions de WAF dans une plateforme de périphérie plus large qui comprend aussi le DNS, le CDN et la protection anti-DDoS. Les offres gratuites reçoivent le Cloudflare Free Managed Ruleset ; les jeux de règles plus larges, les contrôles, les analyses et les capacités de gestion des bots dépendent de l'offre choisie et des options.
Le WAF gratuit de Cloudflare suffit-il ?
Cela dépend de la surface d'attaque de l'application, des règles nécessaires, des besoins de journalisation et de rétention, des contrôles d'API ou de bots, des exigences de support et de votre tolérance aux faux positifs. Le Free Managed Ruleset peut servir de socle utile, mais l'authentification, les paiements ou les données réglementées ne correspondent pas automatiquement à une offre payante précise. Comparez les limites de fonctionnalités actuelles et validez-les au regard de votre modèle de menace.
Quelle est la différence entre un WAF et un pare-feu ?
Un pare-feu réseau classique filtre surtout le trafic à partir des informations des couches 3 et 4 : adresses, protocoles et ports. Un WAF évalue les requêtes HTTP(S) de couche 7, y compris les en-têtes, chemins, paramètres et contenus de corps configurés. Les produits de sécurité modernes peuvent brouiller ces frontières, mais les deux contrôles restent complémentaires plutôt qu'interchangeables.
Qu'est-ce que le WAAP et en quoi diffère-t-il d'un WAF ?
WAAP signifie Web Application and API Protection. C'est plus large qu'un WAF classique : les éditeurs y combinent en général des règles WAF avec la découverte ou l'application de politiques d'API, la gestion des bots et des contrôles anti-DDoS ou anti-abus au niveau applicatif. Le contenu exact du bundle varie selon le fournisseur, donc le WAAP ne doit pas être traité comme un ensemble de fonctions standardisé.
Ai-je besoin d'un WAF si mon framework valide déjà les entrées ?
Pas toujours. Les contrôles du framework réduisent le risque, mais ils ne couvrent pas tous les schémas d'abus automatisé. N'ajoutez un WAF que lorsqu'il répond à un risque identifié qui justifie son coût et son réglage.
