La plupart des équipes activent Cloudflare WAF comme si elles installaient un antivirus : une fois configuré, le problème est résolu. Cette prémisse est fausse, et le prix à payer si on ne la comprend pas est un faux sentiment de sécurité qui peut être plus dangereux que l’absence de protection du tout.
WAF est une couche efficace contre une classe spécifique de menaces. Contre une autre classe, cela crée une friction et non une barrière. Connaître la différence détermine la manière dont vous calibrez le système et ce qui doit être construit au niveau de l'application.
Ce que font réellement les ensembles de règles gérés
Les règles gérées couvrent les classes d'attaques les plus courantes : injection SQL, scripts intersites, traversée de répertoires, téléchargement de shell Web, exploitation de CVE connus dans des frameworks populaires. Ils fonctionnent par correspondance de signatures : le moteur inspecte la demande et vérifie si des modèles correspondent à ceux enregistrés dans les règles.
Ce modèle présente une limitation intrinsèque : il opère sur la forme de la demande, et non sur sa signification pour l'application. Une règle qui détecte ' OR 1=1 -- dans un paramètre de requête déclenchera à la fois une attaque SQLi et un utilisateur légitime recherchant des didacticiels SQL. La règle n'a aucun moyen de savoir ce que ce paramètre représente dans le contexte de votre application : elle ne voit que les octets.
Cela génère des faux positifs prévisibles. Dans les applications dotées d'éditeurs de texte enrichi, les points de terminaison qui acceptent le HTML comme entrée légitime se bloquent sur les règles XSS. Les API qui reçoivent du JSON avec des caractères spéciaux entrent en conflit avec les règles SQLi. La protection est réelle, mais elle n'est pas chirurgicale.
Ce qu'un attaquant patient peut faire
Les ensembles de règles gérés sont excellents contre les attaques de base : scanners automatisés, outils comme sqlmap en mode standard, script kiddies qui déclenchent des charges utiles génériques. Quiconque utilise ces vecteurs sans personnalisation cliquera sur WAF et s'arrêtera là.
Le scénario différent est que l'attaquant sait quel WAF protège la cible – souvent des informations publiques via des en-têtes, des cookies ou un comportement de réponse. Fort de ces connaissances, il teste systématiquement les techniques de contournement : encodages inhabituels (encodage d'URL à plusieurs niveaux, normalisation unicode, casse mixte dans les mots-clés SQL), charges utiles fragmentées dans des corps volumineux, combinaisons exploitant la limite de traitement du moteur.
Face à un attaquant déterminé qui personnalise les charges utiles pour une cible spécifique, WAF ajoute du travail, pas de l'impossibilité. Cela a toujours de la valeur : augmenter le coût d’une attaque réduit le nombre d’attaquants prêts à payer pour cela. Mais il ne s’agit pas d’une barrière absolue et il est dangereux de la traiter comme telle.
Il existe une catégorie de vulnérabilité dans laquelle WAF ne convient tout simplement pas : la logique métier. Si votre application permet à un utilisateur d'afficher les données d'un autre utilisateur en manipulant les identifiants dans l'URL (IDOR), WAF ne le détectera pas. La requête est formellement valide, sans charge utile malveillante. Le problème réside dans la logique de l’application, et la seule protection efficace réside dans le code.
## Niveaux et ce que chaque plan couvre réellement
La protection DDoS de couches 3 et 4 est disponible sur tous les forfaits, toujours activée et sans configuration : atténuation volumétrique à la périphérie, avant que le trafic n'atteigne votre infrastructure.
Le WAF de couche 7 – avec règles gérées – démarre avec le forfait Pro à 20 $ par mois. Ce niveau débloque l’ensemble de règles gérées par Cloudflare et l’ensemble de règles de base OWASP. Le plan gratuit n'autorise que 5 règles personnalisées, sans accès à aucun ensemble de règles gérées. Pour la plupart des applications avec de réelles exigences de sécurité, Pro est le sol minimum acceptable.
Les actions disponibles par règle sont : Bloquer (renvoie immédiatement 403), Défi (affiche un défi JavaScript que les robots ne peuvent pas résoudre), Défi géré (Cloudflare décide automatiquement du niveau du défi), Journal (journalise sans agir), Ignorer (ignore des règles spécifiques ou des groupes entiers) et Autoriser (réussit sans inspection). La composition de ces actions est l’endroit où se produit une grande partie de l’étalonnage.
Un détail qui invalide tout
Il existe un prérequis qui n'est pas évident dans la documentation initiale : WAF ne fonctionne que pour les enregistrements DNS avec le proxy Cloudflare actif — ce que l'interface appelle « cloud orange ». Les enregistrements configurés comme DNS uniquement (icône grise) pointent directement vers l'adresse IP source. Le trafic ne passe pas par Cloudflare, donc aucune règle WAF, aucune atténuation DDoS en périphérie, aucun défi JavaScript ne s'applique.
Cela affecte les sous-domaines laissés uniquement DNS pour des raisons de commodité : environnements de test, API internes accessibles de l'extérieur, services auxiliaires. Si l’attaquant découvre ces sous-domaines – et les outils d’énumération DNS rendent cela trivial – il dispose d’un chemin direct vers l’origine sans passer par le WAF. Le mappage de vos enregistrements DNS et de l'état de chacun doit faire partie de l'audit de sécurité.
Ce que votre équipe doit décider avant d'activer
L'activation d'ensembles de règles gérés sans période d'observation est une recette pour bloquer le trafic légitime en production. Le chemin opérationnel sûr commence avec toutes les règles en mode Log : vous voyez ce qui serait bloqué sans rien bloquer, analysez le schéma de déclenchement et identifiez les faux positifs avant de passer au blocage ou au défi.
La décision la plus critique est de savoir comment gérer les règles qui ne se déclenchent pas correctement. La désactivation globale de la règle crée une faille pour l’attaque réelle contre laquelle elle protège. La bonne réponse est une règle Skip dont la portée est précise : cette règle gérée spécifique, sur ce chemin spécifique, pour cette condition spécifique. La portée fermée préserve la couverture dans le reste de l’application.
Il convient également de décider à l’avance du seuil de sensibilité du jeu de règles de base de l’OWASP. Cela fonctionne par score accumulé : chaque règle qui se déclenche ajoute des points, et l'action se produit lorsque le total dépasse une limite configurable. Une limite trop basse bloque le trafic légitime ; trop élevé, il rate les attaques sophistiquées. Le seuil de rentabilité dépend de la nature de votre candidature et du profil de trafic que vous avez observé.
Un WAF bien configuré constitue une défense solide contre la plupart des attaques que vous recevrez en pratique. Le problème est que « bien configuré » nécessite une itération, pas seulement une activation.
A lire aussi
- WAF + Rate Limiting + Bot Management : le tiercé gagnant de la protection des périphéries
- Sécurité des applications : Guide de protection mobile -DNSSEC avec Cloudflare : ce qu'il protège, ce qu'il ne protège pas et comment l'activer sans problème
- DNS proxy vs DNS uniquement : ce qui change et quand chaque mode a du sens -Cloudflare Durable Objects : État cohérent à la périphérie – ce qui change vraiment
- Protection contre les fuites de données : Guide de sécurité