Cloudflare WAF — Configuration des Règles de Sécurité

Le WAF Cloudflare bloque plus de 57 milliards de cybermenaces par jour en 2026 selon les statistiques publiées par l'entreprise — SQL injection, XSS, RCE, path traversal et scans automatisés constituent l'essentiel du volume. Configurer ce WAF correctement ne se résume pas à activer quelques règles managées : il faut comprendre l'ordre d'évaluation des règles, choisir les bons modes (block, challenge, log), paramétrer le rate limiting en fonction du profil de trafic réel, et construire des règles personnalisées qui traitent les cas d'angle que les rulesets génériques ne couvrent pas. Ce guide détaille la configuration complète, du setup initial jusqu'aux règles avancées de protection des APIs et à la gestion des faux positifs.

Architecture du WAF Cloudflare : comprendre avant de configurer

Le WAF Cloudflare opère au niveau 7 (couche applicative) et inspecte chaque requête HTTP/HTTPS avant qu'elle n'atteigne votre serveur d'origine. Il est composé de quatre modules qui s'exécutent dans un ordre précis : les Custom Rules (règles personnalisées), les Rate Limiting Rules, les Managed Rulesets (OWASP, Cloudflare Managed, Exposed Credentials) et les dynamically generated signatures. Comprendre cet ordre est indispensable pour éviter que vos règles de whitelist ne soient ignorées.

Les Custom Rules sont évaluées en premier — c'est le point d'entrée pour autoriser les trafics légitimes (IPs de monitoring, CDN tiers, outils de pentest autorisés) avant que les rulesets génériques ne les bloquent. Si une Custom Rule retourne une action Skip ou Allow, les modules suivants ne sont pas évalués pour cette requête. C'est le mécanisme de whitelist recommandé.

Configurer les rulesets managés : OWASP et Cloudflare Managed

Le Cloudflare Managed Ruleset contient plusieurs centaines de signatures maintenues par les équipes de threat intelligence de Cloudflare. Il couvre les vecteurs d'attaque les plus courants : injection SQL, XSS réfléchi et stocké, Remote Code Execution, path traversal, SSRF, et upload de fichiers malveillants. Ce ruleset est mis à jour automatiquement — contrairement aux rulesets que vous maintenez vous-même.

La procédure correcte pour l'activer sans casser la production : activez d'abord chaque groupe de règles en mode Log, attendez 48h minimum, analysez les logs dans Security → Events pour identifier les requêtes légitimes qui auraient été bloquées, puis créez les Custom Rules de whitelist nécessaires, et enfin passez en mode Block. Cette approche itérative est documentée dans les recommandations officielles Cloudflare et évite 95 % des incidents de faux positifs.

Retour terrain : Sur un client SaaS B2B avec une API REST consommée par des intégrateurs tiers, l'activation directe en mode Block du Cloudflare Managed Ruleset a bloqué immédiatement les requêtes POST contenant des payloads JSON avec des champs nommés operator ou query — déclenchant la règle SQLi par correspondance sur des termes légitimes. Deux semaines de logs ont permis d'identifier 23 patterns legítimos à whitelister avant de repasser en Block. La leçon : une API JSON mal documentée + WAF en Block direct = incident certain.

Comment configurer les règles personnalisées (Custom Rules) ?

Les Custom Rules sont l'outil le plus puissant du WAF Cloudflare. Elles permettent d'exprimer n'importe quelle logique de filtrage en utilisant le Wireshark-like Rule Builder ou le langage Firewall Rules Expression (syntaxe proche de Wireshark Display Filters). Chaque règle peut déclencher une action : Block, Challenge (CAPTCHA), JS Challenge, Log, Skip, ou une combinaison.

Exemples de règles personnalisées typiques :

Whitelist IP de monitoring : (ip.src in {203.0.113.10 198.51.100.5}) and (http.request.uri.path contains "/health") → action Skip (ignore les règles suivantes). Sans cette règle, vos sondes Pingdom, Datadog ou UptimeRobot déclencheront régulièrement les règles rate limiting ou WAF.

Blocage géographique ciblé : (ip.geoip.country in {"CN" "RU" "KP" "IR"}) and (http.request.uri.path contains "/admin") → action Block. Utile pour protéger les interfaces d'administration sans bloquer l'intégralité du trafic de ces pays.

Blocage User-Agent malveillants : (http.user_agent contains "sqlmap") or (http.user_agent contains "Nikto") or (http.user_agent contains "Acunetix") → action Block. Cette règle bloque les scanners automatisés les plus courants sur la base de leur User-Agent — les attaquants sophistiqués le modifient, mais ça filtre l'essentiel du scan de masse.

Rate Limiting : protéger les APIs et les formulaires

Le rate limiting Cloudflare permet de limiter le nombre de requêtes par IP, par en-tête, par cookie ou par JA3 fingerprint sur une fenêtre temporelle glissante. Il est particulièrement critique pour les endpoints d'authentification (login, reset de mot de passe, 2FA), les APIs publiques et les formulaires de contact qui attirent le spam.

Configuration recommandée pour un endpoint d'authentification : limite de 5 tentatives par IP sur 60 secondes, action Challenge (CAPTCHA) pour ne pas bloquer les utilisateurs légitimes qui ont fait des erreurs de frappe. Si la tentative dépasse 20 essais sur 5 minutes : Block avec durée 1h. Cette double règle combine friction progressive et blocage dur.

Pour une API REST authentifiée via JWT ou API Key, le rate limiting doit s'appuyer sur l'en-tête d'authentification plutôt que sur l'IP — un même client légitime peut utiliser plusieurs IPs (mobile, bureau, VPN). Cloudflare Advanced Rate Limiting (plan Pro+) permet de rater-limiter sur des expressions incluant des en-têtes HTTP : http.request.headers["x-api-key"].

Protection des APIs avec le WAF Cloudflare

Les APIs REST et GraphQL présentent des vecteurs d'attaque différents des applications web classiques : injection dans les paramètres JSON, mass assignment, BOLA (Broken Object Level Authorization), et abus de rate. Le WAF généraliste couvre partiellement ces vecteurs — il faut le compléter avec des règles spécifiques.

Cloudflare API Gateway (plan Enterprise) ajoute une couche de validation de schéma JSON/OpenAPI : toute requête qui ne respecte pas le schéma de l'API déclaré est rejetée avant même d'atteindre votre backend. Pour les plans inférieurs, vous pouvez simuler ce comportement avec des Custom Rules qui vérifient la présence du Content-Type application/json et rejettent les requêtes sans authentication header sur les paths /api/*.

La protection GraphQL mérite une attention particulière : les requêtes GraphQL sont toutes des POST sur un seul endpoint, ce qui rend le rate limiting par URL inefficace. Cloudflare propose des règles spécifiques pour inspecter la profondeur des queries GraphQL et bloquer les attaques par introspection abusive ou les nested queries DOS.

Gérer les faux positifs sans compromettre la sécurité

Le problème n°1 des WAF en production est la génération de faux positifs — des requêtes légitimes bloquées parce qu'elles ressemblent syntaxiquement à une attaque. L'approche correcte n'est pas d'affaiblir les règles globalement mais de créer des exceptions précises et documentées.

Cloudflare propose trois niveaux d'exception :

• Rule override par URI : désactive une règle spécifique pour un chemin d'URL précis (ex. désactiver la règle SQLi 100015 uniquement sur /admin/query-builder).
• Rule override par IP : exclut une IP ou un range du ruleset managé (ex. l'IP de votre outil de pentest).
• Custom Rule Skip : la méthode la plus granulaire — créez une Custom Rule qui matche exactement votre cas légitime et retourne l'action Skip avec le paramètre "skip all remaining rules" ou "skip specific ruleset".

Documentez chaque exception avec sa justification dans les notes de la règle — les audits de sécurité demandent systématiquement pourquoi certaines règles WAF sont désactivées. Une exception non documentée est un risque de sécurité latent. Pour approfondir l'audit de sécurité applicatif, consultez notre guide sur Wazuh SIEM/XDR qui couvre la corrélation des événements WAF avec les alertes de détection d'intrusion.

Surveillance et alertes WAF

La section Security → Events du dashboard Cloudflare affiche le flux en temps réel des requêtes bloquées, challengées ou loggées par le WAF. Les filtres permettent d'analyser par règle déclenchée, par IP source, par pays, par User-Agent ou par URI. L'export CSV est disponible pour les 72 dernières heures sur tous les plans.

Pour une rétention plus longue et une corrélation avec d'autres sources, activez Cloudflare Logpush vers un SIEM (Splunk, Elastic, Datadog) ou un bucket S3. Les WAF logs Cloudflare sont au format JSON newline-delimited et incluent le champ WAFAction, WAFRuleID, WAFRuleMessage et le score d'attaque. Cette visibilité est indispensable pour une organisation qui pratique la détection et réponse aux incidents — voir notre guide sur la sécurité réseau cloud pour contextualiser les logs WAF dans une architecture plus large.

Configurez des alertes email ou webhook (via Cloudflare Notifications) pour les événements critiques : augmentation soudaine du nombre de blocks (+500% vs baseline), détection de règles OWASP critical, ou activation du mode Under Attack. Ces alertes permettent une réponse en moins de 5 minutes sur les incidents actifs.

Intégration avec OWASP et référentiels de sécurité

Le Cloudflare OWASP Core Ruleset implémente le ModSecurity Core Rule Set (CRS) version 3.3+ en mode scoring : chaque règle OWASP ajoute un score à la requête, et si le score total dépasse le seuil configuré (par défaut : 25 pour High, 60 pour Medium), l'action configurée est déclenchée. Ce mode évite les faux positifs sur des requêtes qui déclenchent une seule règle mais n'ont pas de profil d'attaque global.

Le seuil OWASP est configurable entre Low (score ≥ 60), Medium (score ≥ 40) et High (score ≥ 25). Commencez avec Low en mode Log, puis montez progressivement vers High en mode Block une fois les faux positifs traités. Le niveau High bloque les attaques les plus sophistiquées mais génère davantage de faux positifs sur les applications avec des entrées utilisateur complexes.

Questions fréquentes sur la configuration du WAF Cloudflare

Le WAF Cloudflare suffit-il à protéger une application contre l'OWASP Top 10 ?

Pas entièrement. Le WAF couvre les vecteurs d'injection (A03), certaines configurations de sécurité défaillantes (A05) et les composants vulnérables connus (A06). En revanche, il ne peut pas détecter les failles logiques métier (IDOR, BOLA), les problèmes d'authentification cassée (A07) ou le logging insuffisant (A09) — ces vulnérabilités relèvent du code applicatif. Le WAF est une couche de défense parmi plusieurs, pas un substitut à un développement sécurisé et à des tests de pénétration réguliers comme ceux proposés dans notre service de pentest.

Comment tester que le WAF fonctionne sans déclencher de vrai blocage ?

Utilisez le chemin de test officiel Cloudflare : envoyez une requête GET vers https://votre-domaine.fr/?=UNION SELECT ALL FROM information_schema AND 1=1 — c'est un payload SQL injection de test reconnu qui doit déclencher le WAF en mode Block avec un code 403. Si la réponse est 200, le WAF n'est pas actif sur ce domaine. Vous pouvez aussi utiliser l'outil wafw00f en mode passif pour vérifier la présence d'un WAF sans envoyer de payloads offensifs.

Quand activer le mode "Under Attack" de Cloudflare ?

Le mode Under Attack présente un challenge JavaScript à 100% des visiteurs avant de leur accorder l'accès — il réduit massivement le trafic illégitime lors d'une attaque DDoS active ou d'un abus volumétrique soudain. Activez-le uniquement en cas d'attaque confirmée, pas en permanence : le challenge génère une latence de 4-5 secondes pour les utilisateurs légitimes et dégrade l'expérience. Désactivez-le dès que l'attaque est absorbée.

Les règles WAF ralentissent-elles les requêtes légitimes ?

Imperceptiblement. L'inspection WAF Cloudflare ajoute environ 1 à 2 ms de latence par requête — elle est réalisée au niveau des PoP edge, pas sur votre serveur d'origine. Cette latence est négligeable comparée au gain de sécurité et au fait que les requêtes attaquantes sont bloquées avant de consommer les ressources de votre backend. Le WAF n'impacte pas les Core Web Vitals de façon mesurable.

Bot Management : protéger au-delà des règles WAF classiques

Les bots malveillants ne déclenchent pas nécessairement les règles WAF classiques parce qu'ils n'envoient pas de payloads d'attaque évidents — ils exécutent des actions légitimes (login, consultation de prix, réservation) mais à une cadence ou depuis des sources qui révèlent leur nature automatisée. Le Credential Stuffing — test en masse de couples identifiant/mot de passe volés — est le vecteur le plus courant : les bots essaient des millions de credentials sur votre page de login en envoyant des requêtes POST structurellement identiques à celles d'un utilisateur humain.

Cloudflare Bot Management (plan Pro+) analyse chaque requête avec un score de bot de 0 à 99 : un score proche de 1 indique un bot automatisé, un score proche de 99 indique un humain. Ce score est calculé à partir de dizaines de signaux : fingerprint JavaScript (détecté par le moteur Cloudflare), comportement TLS (JA3/JA4 fingerprint), timing des requêtes, présence de cookies Cloudflare antérieurs, et réputation de l'IP. Ce scoring est plus fiable que les User-Agent checks car les bots sophistiqués imitent les navigateurs mais ne peuvent pas reproduire tous les signaux comportementaux.

Configurez des Custom Rules qui utilisent le champ cf.bot_management.score : par exemple, bloquez les requêtes avec un score bot < 30 sur votre endpoint de login, challengez les scores 30-50, et laissez passer les scores > 50. Cette graduation évite les faux positifs sur les outils d'automatisation légitimes (tests CI, monitoring) qui ont souvent un score intermédiaire.

Cloudflare API Shield : valider les schémas d'API automatiquement

Cloudflare API Shield (disponible sur les plans Enterprise) ajoute une couche de validation de schéma API en amont du WAF. Il apprend automatiquement le schéma de votre API en analysant le trafic légitime pendant une phase d'apprentissage, puis peut bloquer toute requête qui s'écarte de ce schéma — paramètres inconnus, types incorrects, méthodes HTTP inattendues. C'est une protection contre les attaques de mass assignment et les injections via des paramètres non documentés.

Pour les équipes qui disposent déjà d'une spécification OpenAPI, API Shield accepte l'import direct du fichier YAML/JSON. La validation est alors basée sur la spécification formelle plutôt que sur l'apprentissage comportemental — c'est plus précis et immédiatement opérationnel sans phase d'apprentissage.

La fonctionnalité API Shield intègre également la détection des Leaked Credentials : si un JWT expiré ou révoqué est utilisé dans une requête API, Cloudflare peut le détecter et bloquer la requête. Combinée avec le rate limiting par token d'API, c'est une défense en profondeur complète pour les APIs exposées publiquement.

Audit de conformité WAF : répondre aux exigences PCI DSS et NIS 2

Les référentiels de conformité imposent des exigences explicites sur les WAF. PCI DSS v4 (Requirement 6.4) exige un WAF actif pour les applications web traitant des données cardholder, avec des règles mises à jour régulièrement et des logs retenus 12 mois. NIS 2 (Article 21) impose des mesures de sécurité proportionnées incluant la protection des applications — un WAF configuré et documenté est une preuve de conformité tangible.

Cloudflare génère des rapports d'activité WAF exportables qui peuvent servir de pièces justificatives pour les audits PCI : volume de requêtes bloquées par catégorie d'attaque, règles actives, et changelog des modifications de configuration. La fonctionnalité Audit Log (dans Account → Audit Log) trace toutes les modifications de configuration avec l'identité de l'opérateur — indispensable pour démontrer la gouvernance de la configuration WAF lors d'un audit.

Pour les organisations soumises à NIS 2, le RSSI doit être en mesure de démontrer que le WAF est correctement configuré, maintenu et supervisé. Notre service RSSI externalisé couvre cet aspect opérationnel et peut prendre en charge la configuration et la supervision du WAF Cloudflare dans le cadre d'un mandat de RSSI temps partagé.

Performance du WAF : impact sur les Core Web Vitals

Un WAF mal configuré peut dégrader les performances perçues par les utilisateurs si des challenges CAPTCHA s'affichent sur des requêtes légitimes. La configuration Cloudflare par défaut minimise cet impact : les challenges JS (transparents pour l'utilisateur) sont préférés aux CAPTCHA visuels pour les requêtes suspectes mais pas confirmées malveillantes. Les challenges visuels ne s'affichent qu'en dernier recours ou en mode Under Attack.

L'inspection WAF elle-même n'impacte pas les Core Web Vitals de façon mesurable : elle s'effectue au niveau des PoP Cloudflare avec une latence inférieure à 2 ms. La vraie variable de performance est la configuration du cache Cloudflare en aval — un WAF qui bloque et rejette au niveau edge évite que les requêtes malveillantes consomment des ressources serveur, ce qui améliore indirectement le Time to First Byte pour le trafic légitime.

Intégration WAF Cloudflare avec les pipelines CI/CD

La gestion du WAF Cloudflare via l'API permet d'intégrer les changements de règles dans les pipelines CI/CD. Chaque déploiement d'une nouvelle version d'API peut déclencher automatiquement la mise à jour des règles WAF correspondantes — par exemple, un nouveau chemin /api/v2/upload ajoute automatiquement une règle de rate limiting via le provider Terraform Cloudflare dans la pipeline GitHub Actions.

Cette approche "Security as Code" garantit que la configuration WAF évolue synchroniquement avec l'application et réduit le risque de décalage entre ce que le WAF protège et ce que l'application expose réellement. Les pull requests qui ajoutent de nouveaux endpoints API peuvent inclure, dans le même commit, les règles WAF associées — revue de sécurité et déploiement de protection sont atomiques. Pour les équipes qui intègrent la sécurité dans leur cycle DevOps, voir notre guide sur le hardening d'infrastructure pour des pratiques complémentaires de sécurisation à la couche système.

Conclusion

Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.