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

Le WAF (Web Application Firewall) de Cloudflare est l'un des pare-feux applicatifs les plus déployés au monde, protégeant des millions de sites web contre les injections SQL, les attaques XSS, les traversées de répertoires, les exploitations de CVE connues et les tentatives de prise de contrôle de comptes. Opérant en couche 7 du modèle OSI, il analyse chaque requête HTTP et HTTPS avant qu'elle n'atteigne votre serveur d'origine, appliquant des centaines de règles de détection mises à jour en temps réel par les équipes de threat intelligence de Cloudflare. En 2026, face à l'explosion des attaques automatisées — bots scrapers, credential stuffing, exploitation de vulnérabilités zero-day — la configuration correcte du WAF est devenue un prérequis non négociable pour toute infrastructure web exposée sur Internet. Ce guide opérationnel détaille l'ensemble des capacités du WAF Cloudflare : règles managées OWASP, règles personnalisées avec le langage d'expression Firewall Rules, rate limiting pour les API et formulaires, gestion des bots, protection des API REST avec API Shield, analyse des logs pour éliminer les faux positifs, et intégration des alertes dans votre chaîne d'observabilité. Des exemples concrets de règles et de configurations sont fournis pour chaque cas d'usage, applicables immédiatement en production.

Qu'est-ce que le WAF Cloudflare et comment il fonctionne

Le WAF Cloudflare est un pare-feu applicatif en mode cloud qui s'interpose entre Internet et votre serveur d'origine. Il opère sur les plans HTTP et HTTPS (couche 7) en analysant les en-têtes, le corps, les paramètres de requête, les cookies et les méthodes HTTP de chaque requête entrante.

Trois modes d'action sont disponibles pour chaque règle : Block bloque la requête et retourne un code 403 ou une page d'erreur personnalisée. Challenge présente une vérification JavaScript (challenge JS) ou un CAPTCHA (Turnstile) pour distinguer les humains des bots. Log (ou Managed Challenge en mode audit) enregistre la requête sans bloquer — idéal pour identifier les faux positifs avant de passer en production.

Cloudflare traite les règles WAF selon un ordre de priorité strict : les règles personnalisées (Custom Rules) sont évaluées avant les règles managées. Les actions les plus sévères (Block) priment sur les moins sévères (Log). L'action finale appliquée à une requête est déterminée par la première règle qui correspond dans l'ordre de priorité configuré.

Le WAF s'appuie sur le réseau anycast Cloudflare : le filtrage se fait au plus près de l'utilisateur, dans le PoP le plus proche, avant même que la requête ne traverse l'Atlantique ou n'atteigne votre datacenter. Cela réduit la charge sur votre serveur d'origine et limite l'exposition de votre infrastructure. Pour une analyse approfondie de votre posture sécurité applicative, consultez notre service d'audit d'infrastructure.

Règles managées Cloudflare et OWASP Core Ruleset

Les règles managées sont des ensembles de règles maintenus par Cloudflare et ses partenaires, couvrant les catégories d'attaques les plus communes. Elles sont disponibles dans l'onglet Security → WAF → Managed Rules.

Le Cloudflare Managed Ruleset contient des centaines de règles couvrant les vulnérabilités critiques connues : exploitation de Log4Shell, vulnérabilités WordPress, Drupal, Magento, Spring4Shell, et les CVE fraîchement publiées. Cloudflare déploie ces règles en quelques heures après la découverte d'une vulnérabilité critique, souvent avant que les patches officiels ne soient disponibles. Cela constitue un filet de sécurité virtuel (virtual patching) précieux, directement lié à la gestion des vulnérabilités que nous décrivons dans notre guide sur le Patch Tuesday.

L'OWASP Core Ruleset (CRS) couvre les 10 catégories de risques OWASP les plus critiques : injections SQL (SQLi), cross-site scripting (XSS), inclusion de fichiers locaux/distants (LFI/RFI), Server-Side Request Forgery (SSRF), traversée de répertoires. La sensibilité est configurable (Low, Medium, High) pour chaque catégorie. En mode High, le taux de faux positifs augmente mais la détection est plus exhaustive.

Pour chaque règle managée, vous pouvez créer des exceptions (Skip) ciblées : exclure une règle pour un chemin spécifique (/api/webhook), un pays, une adresse IP de confiance ou un User-Agent de monitoring. Les exceptions permettent d'activer les règles managées en mode Block sans impacter les flux légitimes.

La configuration recommandée pour un démarrage : activez les deux rulesets en mode Log pendant 72h, analysez les logs, créez les exceptions nécessaires, puis basculez en mode Block.

Règles personnalisées — syntaxe et cas d'usage

Les Custom Rules (règles personnalisées) permettent de créer des règles sur mesure en utilisant le langage d'expression Firewall Rules de Cloudflare, basé sur une syntaxe déclarative inspirée de Wireshark. Elles s'appliquent avant les règles managées.

Exemples de champs disponibles : http.request.uri.path, http.request.method, http.host, ip.src.country, http.user_agent, http.request.headers, cf.threat_score. Le Threat Score Cloudflare (0-100) évalue le niveau de risque associé à une IP basé sur les données de réputation du réseau Cloudflare.

Exemples de règles personnalisées utiles :

Bloquer les pays hors périmètre : (ip.src.country ne "FR" and ip.src.country ne "BE" and ip.src.country ne "CH" and http.request.uri.path contains "/admin") → Block. Protège l'administration d'un site français d'accès hors zone géographique attendue.

Challenger les IPs avec Threat Score élevé : (cf.threat_score ge 25) → Managed Challenge. Présente un Turnstile aux IPs suspectes sans bloquer les utilisateurs légitimes.

Bloquer les méthodes HTTP non souhaitées : (http.request.method in {"DELETE" "TRACE" "OPTIONS"} and not http.request.uri.path contains "/api/") → Block. Limite les méthodes dangereuses sur les ressources non-API.

La documentation complète du langage d'expression est disponible sur developers.cloudflare.com/waf/custom-rules. La documentation générale du WAF est sur developers.cloudflare.com/waf.

Rate Limiting — protéger les API et formulaires

Le Rate Limiting permet de limiter le nombre de requêtes qu'une IP peut effectuer sur une URL donnée pendant une fenêtre de temps. C'est la protection principale contre le credential stuffing, le brute force et les scrapers agressifs.

Configuration type pour un endpoint de connexion : Chemin : /login ou /wp-login.php. Méthode : POST uniquement. Seuil : 5 requêtes par minute. Action : Block pendant 10 minutes. Caractéristiques : par IP source. Ce paramétrage bloque efficacement les tentatives de force brute tout en permettant aux utilisateurs légitimes (qui ne soumettent pas un formulaire 5 fois par minute) de continuer normalement.

Pour les API REST, le rate limiting doit être adapté aux volumétries légitimes. Un endpoint /api/search peut légitimement recevoir 60 requêtes par minute d'une application mobile, alors qu'un endpoint /api/export ne devrait pas dépasser 5 requêtes par heure. Définissez des règles de rate limiting par endpoint selon les spécifications de votre API.

Le Rate Limiting Advanced (plan Pro et supérieur) permet de comptabiliser par combinaison de champs (IP + User-Agent + ASN), de déclencher sur des codes de réponse spécifiques (ex : bloquer une IP qui reçoit 10 codes 401 en une minute), et d'appliquer des pénalités progressives (challenge d'abord, puis block).

Pour les applications WordPress, protégez systématiquement /wp-login.php (seuil 5/min), /xmlrpc.php (bloquer complètement dans une règle personnalisée si non utilisé), et /wp-json/wp/v2/users (énumération des utilisateurs). Ces protections s'inscrivent dans une démarche de pentest cloud qui inclut l'évaluation des expositions applicatives.

Bot Management — Super Bot Fight Mode et Turnstile

La gestion des bots est l'un des défis majeurs des WAF modernes. En 2026, plus de 40% du trafic web mondial est généré par des bots — scrapers, crawlers, bots malveillants, outils d'automatisation. Le Bot Management Cloudflare classe automatiquement chaque requête selon son origine probable.

Le Super Bot Fight Mode (plans Pro et supérieur) distingue les bots vérifiés (Googlebot, Bingbot, UptimeRobot), les bots probables (automatisés mais non identifiés), et les bots définitivement automatisés. Pour chaque catégorie, vous pouvez choisir Allow, Block, Challenge ou No Action. Les bots vérifiés (SEO, monitoring) doivent être autorisés ; les bots probables peuvent être challengés ; les bots automatisés non identifiés doivent être bloqués ou challengés selon votre seuil de tolérance.

Cloudflare Turnstile est l'alternative respectueuse de la vie privée aux CAPTCHAs traditionnels de Google reCAPTCHA. Il utilise des défis non-interactifs basés sur des signaux comportementaux (mouvement souris, temps de chargement, empreinte navigateur) pour distinguer humains et bots sans afficher d'images à classifier. Turnstile est disponible gratuitement pour tous les sites Cloudflare et s'intègre via un simple snippet JavaScript.

Le Bot Score (0-100) est disponible dans les logs Cloudflare et peut être utilisé comme condition dans vos règles personnalisées : (cf.bot_management.score lt 30) → Challenge. Plus le score est bas, plus la requête ressemble à du trafic bot. Combiner le Bot Score avec le Threat Score et le JA3 fingerprint permet une détection très précise des bots sophistiqués qui imitent les navigateurs réels.

La documentation officielle sur les bots est disponible sur developers.cloudflare.com/bots.

Protéger les API REST avec API Shield

API Shield est la fonctionnalité dédiée de Cloudflare pour la protection des API REST, GraphQL et gRPC. Elle va au-delà du WAF classique en appliquant une validation du schéma (Schema Validation), une authentification mTLS et une détection d'anomalies basée sur les volumes.

La Schema Validation permet d'importer votre spécification OpenAPI (fichier JSON ou YAML) dans Cloudflare. Toute requête dont les paramètres, types de données ou méthodes ne correspondent pas au schéma est automatiquement bloquée. Cela élimine une classe entière d'attaques par manipulation de paramètres sans écrire une seule règle personnalisée.

L'authentification mTLS impose que les clients API présentent un certificat client valide émis par votre autorité de certification. Cloudflare vérifie le certificat client avant même d'évaluer les règles WAF. Les requêtes sans certificat valide sont bloquées au niveau TLS. C'est la protection la plus robuste pour les API machine-to-machine.

La détection d'anomalies API (Sequence Analytics) analyse les patterns de navigation de vos endpoints pour détecter des comportements anormaux : accès à des endpoints dans un ordre inhabituel, consommation excessive de certains endpoints, utilisation d'endpoints cachés non documentés. Ces anomalies peuvent indiquer une reconnaissance en vue d'une attaque.

L'intégration d'API Shield avec vos processus de conformité NIS 2 et DORA est détaillée dans nos pages dédiées : NIS 2 et conformité DORA. Pour les environnements Azure AD/Entra ID, la combinaison API Shield + mTLS + Entra ID constitue une architecture Zero Trust applicative robuste.

Analyser les logs WAF et gérer les faux positifs

La gestion des faux positifs est l'aspect le plus chronophage de l'opération d'un WAF. Un faux positif est une requête légitime bloquée par une règle WAF. Trop de faux positifs dégradent l'expérience utilisateur ; pas assez de règles exposent à des attaques réelles.

Depuis l'onglet Security → Events, Cloudflare affiche en temps réel toutes les actions WAF (Block, Challenge, Log) avec le détail de la requête : IP, pays, User-Agent, URI, méthode, règle déclenchée et motif. Utilisez les filtres pour isoler les événements par règle, par action ou par origine géographique.

Lors de la mise en place, commencez en mode Log (audit mode) : toutes les règles sont évaluées mais aucune n'est bloquante. Après 72h de trafic représentatif, exportez les logs (via l'API ou Logpush) et analysez les règles qui auraient déclenché le plus d'actions. Pour chaque règle à fort volume, vérifiez si les requêtes sont légitimes ou malveillantes.

Pour créer une exception ciblée sans désactiver toute une règle managée : dans "Managed Rules", cliquez sur la règle concernée et ajoutez une exception par chemin URL (/api/webhook), par IP de confiance, ou par User-Agent de vos outils de monitoring. Les exceptions sont préférables à la désactivation totale d'une règle.

En production, planifiez une revue mensuelle des événements WAF pour détecter les nouvelles attaques, ajuster les seuils de rate limiting et mettre à jour les exceptions devenues obsolètes. Cette revue s'intègre naturellement dans le processus d'audit d'infrastructure périodique.

Intégration avec les alertes et l'observabilité

Une configuration WAF efficace n'est pas statique. Elle doit être connectée à votre chaîne d'alerting pour réagir rapidement aux incidents de sécurité et aux changements de comportement du trafic.

Les Cloudflare Notifications permettent de créer des alertes par e-mail, webhook ou API sur des événements WAF : pic de blocages, attaque DDoS détectée, règle managée nouvelle activée. Depuis "Account → Notifications", configurez une alerte "Security Level Change" et "DDoS Attack Alert" au minimum.

Pour l'intégration webhook, Cloudflare envoie les notifications en JSON vers une URL de votre choix : Slack, Teams, PagerDuty, OpsGenie. Le payload inclut le type d'événement, l'horodatage, le domaine affecté et les détails de l'attaque. Configurez un webhook vers votre canal Slack de sécurité pour une visibilité en temps réel.

Cloudflare Logpush (plan Business/Enterprise) exporte les logs WAF en temps réel vers votre SIEM (Splunk, Elastic/Kibana, Datadog, Amazon S3). Chaque log inclut le timestamp, l'IP source, le pays, l'action WAF, la règle déclenchée, le score de menace et les en-têtes HTTP. Cette télémétrie est indispensable pour les organisations soumises à NIS 2 qui doivent conserver des preuves d'audit de sécurité pendant plusieurs années.

Pour les plans gratuits et Pro sans Logpush, l'API Cloudflare (GET /client/v4/zones/{zone_id}/security/events) permet de récupérer les événements des 72 dernières heures. Automatisez cette collecte via un script cron et stockez les données dans votre propre système de logging pour la conformité. Notre guide sur la gestion des vulnérabilités détaille comment intégrer ces logs dans votre processus de veille et de réponse aux incidents.

FAQ — Cloudflare WAF

Quelle est la différence entre le WAF Cloudflare et un pare-feu réseau traditionnel ?

Un pare-feu réseau opère en couches 3 et 4 (IP, TCP/UDP) et filtre le trafic selon les adresses IP, ports et protocoles. Il ne comprend pas le contenu des requêtes HTTP. Le WAF Cloudflare opère en couche 7 (applicative) et inspecte le contenu des requêtes HTTP : paramètres GET/POST, en-têtes, cookies, corps JSON/XML. Il peut ainsi détecter une injection SQL dans un paramètre de formulaire, un XSS dans un en-tête HTTP ou une traversée de répertoire dans un chemin URL. Les deux protections sont complémentaires et non substituables : un pare-feu réseau protège l'infrastructure, le WAF protège l'application. Pour une protection optimale, les deux doivent être en place simultanément.

Le WAF Cloudflare peut-il protéger une API GraphQL ou gRPC ?

Oui, Cloudflare supporte la protection des API GraphQL et gRPC. Pour GraphQL, API Shield propose une validation du schéma GraphQL et une limitation des requêtes trop complexes (protection contre les attaques par queries imbriquées). Pour gRPC, le proxy Cloudflare supporte HTTP/2 et peut appliquer des règles WAF sur les messages protobuf. Cependant, l'inspection du contenu des messages gRPC chiffrés (au niveau applicatif) est limitée sans décryptage TLS, qui est natif dans le proxy Cloudflare. La configuration de ces protections nécessite généralement un plan Enterprise avec le support API Shield avancé. Pour des architectures API complexes, un audit préalable de votre exposition est recommandé via notre service de pentest cloud.

Comment configurer le WAF Cloudflare pour éviter de bloquer Googlebot ?

Googlebot et les autres robots des moteurs de recherche légitimes sont automatiquement identifiés par Cloudflare dans la catégorie "Verified Bots". En activant Super Bot Fight Mode, assurez-vous que l'option "Verified Bots" est configurée sur "Allow" (et non Block ou Challenge). Cloudflare vérifie l'authenticité de Googlebot en contrôlant que le reverse DNS de l'IP correspond à googlebot.com et que le forward DNS confirme l'IP. Cette vérification élimine les faux Googlebots. Pour les règles personnalisées qui pourraient bloquer les crawlers, ajoutez une condition cf.client.bot pour exempter les bots vérifiés. Ne créez jamais de règle de blocage par User-Agent "Googlebot" : les vrais Googlebots sont protégés par la vérification réseau, et bloquer par User-Agent bloque uniquement les faux Googlebots légitimement suspects.

Comment le WAF Cloudflare gère-t-il les connexions HTTPS et l'inspection TLS ?

Cloudflare termine la connexion TLS au niveau de son réseau (TLS termination au edge), décrypte le trafic, l'inspecte avec le WAF, puis établit une connexion TLS séparée vers votre serveur d'origine. Ce mécanisme est transparent pour l'utilisateur et nécessaire pour que le WAF puisse inspecter le contenu HTTPS. Côté confidentialité, Cloudflare garantit contractuellement de ne pas analyser le contenu au-delà de ce qui est nécessaire pour la détection des menaces. Pour les données ultra-sensibles (données médicales, données financières DORA), évaluez si ce modèle de confiance est acceptable dans votre contexte réglementaire. Une alternative est le mode "Full Strict" qui garantit une connexion TLS chiffrée jusqu'au serveur d'origine avec validation du certificat.

Comment dimensionner les règles de rate limiting sans bloquer les utilisateurs légitimes lors de pics de trafic ?

Le dimensionnement du rate limiting doit partir des métriques réelles de votre application. Activez d'abord le rate limiting en mode Log (sans blocage) pendant 2 à 4 semaines couvrant des périodes de pointe (soldes, événements, campagnes marketing). Analysez les centiles 95 et 99 des requêtes par IP par minute pour vos endpoints critiques. Définissez votre seuil à 2 fois le P99 légitime observé — cela laisse une marge confortable tout en bloquant les abus. Pour les endpoints publics avec des accès légitimes élevés (API mobile), préférez un rate limiting par token d'authentification plutôt que par IP, surtout si vos utilisateurs se trouvent derrière des NAT partagés (bureau, université). Prévoyez également une procédure de déblocage rapide pour les incidents de faux positifs en production.