Configuration du WAF Cloudflare : un déploiement sûr et testable

Publié le

14 juil. 2026

Mis à jour le

15 juil. 2026

Temps de lecture

23 min de lecture

À l'échelle où opère une couche d'orchestration d'edge managée — plusieurs zones, plusieurs équipes, et souvent plus d'un fournisseur en amont devant la même origine — une mauvaise configuration du WAF ne reste presque jamais confinée à un seul tableau de bord. Ce guide traite la configuration du WAF Cloudflare comme une discipline opérationnelle : un déploiement par étapes appuyé sur des preuves, des exceptions ciblées et un rollback répété à l'avance, afin qu'un gain de sécurité n'arrive jamais sous la forme d'une panne silencieuse pour les navigateurs, les API ou les webhooks partenaires.

Prenons le cas d'Acme Shop, une boutique en ligne fictive qui sert de fil rouge à ce guide. Sa vitrine www.acme-shop.example reçoit du trafic navigateur, tandis que api.acme-shop.example accepte un webhook d'inventaire signé et une API mobile. L'objectif du déploiement est de protéger la vitrine proxifiée avec les Managed Rules et un canari Custom Rule ciblé sur un host et un chemin précis, sans jamais transformer le webhook signé ou une réponse API JSON valide en page de challenge HTML. Acme Shop ne teste que contre un endpoint de staging inoffensif, jamais avec de véritables payloads d'exploitation en production. Le résultat attendu : un journal de changement qui montre l'ordre des rulesets, le comportement attendu des navigateurs et des API, les preuves de faux positifs, et l'exception ou la règle unique à annuler si une requête légitime échoue.

Un web application firewall est plus efficace lorsqu'il est exploité comme un contrôle mesuré et non comme un interrupteur ponctuel. Commencez par le chemin de trafic protégé, établissez une baseline, déployez un changement étroit, observez le trafic mitigé comme légitime et conservez un chemin de rollback rapide. C'est particulièrement important pour les API et les clients non navigateurs, pour lesquels un challenge interactif peut être une interruption de service plutôt qu'un contrôle de sécurité.

Cloudflare WAF évalue les requêtes web et API entrantes à l'aide de rulesets. Ses Managed Rules fournissent une couverture de détection maintenue, tandis que les Custom Rules permettent à une équipe d'exprimer des conditions et actions propres à l'application. Ni les uns ni les autres ne remplacent un code applicatif sécurisé, l'authentification, les contrôles de débit ou un firewall d'origine qui rejette le trafic direct.

Prérequis

• Un hostname Cloudflare proxifié et une politique d'accès à l'origine confirmée qui autorise Cloudflare tout en refusant le trafic direct non fiable.
• Un plan Enterprise pour l'action Custom Rule Log utilisée par le canari décrit plus bas ; ne configurez pas cette règle d'observation particulière sur les plans où Log n'est pas disponible.
• Un accès à la zone adapté à la modification et à la revue de la configuration WAF, ainsi qu'un responsable de rollback désigné.
• Un inventaire des pages navigateur, API, clients mobiles, webhooks, intégrations partenaires, contrôles de disponibilité et routes administratives.
• Un hostname de staging ou un périmètre canari de production avec un endpoint de test inoffensif et des identifiants client représentatifs.
• Un accès à Cloudflare Security Events, aux logs origine/application et aux enregistrements de déploiement avec des horodatages synchronisés.

Avant de modifier la politique, capturez une courte baseline pour les parcours navigateur et machine critiques. Pour un endpoint de santé non sensible, une simple requête peut confirmer le statut et les en-têtes de réponse :

curl -sS -D - -o /dev/null https://api.example.com/health

Pour les API authentifiées, utilisez un principal de test approuvé et un endpoint hors production ou canari. Ne placez pas de bearer tokens, cookies, URL signées, corps de requête ou identifiants client dans l'historique shell, des terminaux partagés, des captures d'écran ou des tickets de support.

Planifier la configuration du WAF Cloudflare comme un changement versionné

Traitez la configuration du WAF Cloudflare comme n'importe quel autre déploiement de production : versionnée, revue et réversible en une seule étape. Deux contraintes déterminent jusqu'où une étape unique peut aller.

• Les quotas de Custom Rules s'appliquent par zone et varient fortement selon le plan : cinq règles en Free, vingt en Pro, cent en Business et mille en Enterprise. Une règle canari, une règle d'incident temporaire et une poignée d'exceptions de managed rules peuvent consommer une part significative de ce budget sur une zone Free ou Pro ; retirez donc les règles de preuve de concept avant qu'elles ne deviennent des occupants permanents qui bloquent un futur changement.
• Configurez via un chemin que votre équipe peut comparer version par version et annuler — le journal d'audit du dashboard lui-même, l'API Cloudflare ou Terraform — de la même façon qu'elle reverrait du code applicatif. Un changement effectué seulement à la main, sans ticket ni commit derrière lui, n'a aucun moyen fiable d'annulation au-delà de la mémoire humaine.

Consignez, pour chaque changement : la règle ou le ruleset exact concerné, sa position par rapport aux règles voisines, le palier de plan dont il dépend (une action Log ou un périmètre Skip qui n'existe que sur certains plans), le responsable et la commande de rollback. C'est cet enregistrement qui transforme « le WAF a bloqué quelque chose » en un diagnostic de deux minutes plutôt qu'en cellule de crise.

Comprendre les couches et l'ordre des règles

Utilisez chaque couche pour sa fonction :

L'ordre des règles modifie le comportement. Cloudflare évalue les Custom Rules dans l'ordre de la liste, et une action terminale telle que Block ou Managed Challenge peut empêcher l'exécution des Custom Rules suivantes. Cloudflare documente un ordre de phases fixe pour ses produits de sécurité : atténuation HTTP DDoS, puis Custom Rules (http_request_firewall_custom), puis Rate Limiting Rules (http_ratelimit), puis Managed Rules (http_request_firewall_managed), puis Super Bot Fight Mode. Un blocage ou un challenge dans une phase antérieure empêche Cloudflare d'évaluer toutes les phases suivantes pour cette requête, y compris les Managed Rules et toute exception de managed rule qui y est configurée. Dans les exceptions de managed rules, un skip ne s'applique qu'aux managed rules exécutées après cette exception, donc l'emplacement est important ; et puisqu'une exception n'ajuste jamais que la phase Managed Rules, elle ne peut pas repêcher une requête déjà bloquée en amont par une règle de rate limiting.

Établissez une carte d'ordre avant le déploiement. Pour chaque règle proposée, écrivez sa correspondance, son action, le type de client attendu, les dépendances, les règles terminales antérieures possibles, les contrôles ultérieurs qu'elle peut empêcher et la commande ou modification de configuration de rollback. Revérifiez la documentation Cloudflare sur l'interopérabilité des fonctionnalités de sécurité actuelle avant de vous appuyer sur une séquence d'exécution, car les phases et intégrations du produit évoluent.

La règle canari d'Acme Shop sous revue

Sur un plan Enterprise, commencez par Log, pas par une action de blocage. Cette expression en Rules language limite le canari à une route de staging isolée et à une valeur de test non secrète et à usage unique. Log est une action Custom Rule réservée à Enterprise ; ce guide traite donc l'accès Enterprise comme un prérequis plutôt que de laisser entendre que le même canari fonctionne sur tous les plans. Placez-la avant toute Custom Rule plus large susceptible d'agir de façon terminale sur la même requête. Ce n'est pas une allowlist et cela ne contourne pas les Managed Rules.

Description : Observer le canari WAF d'Acme Shop uniquement
Expression :  (http.host eq "staging.acme-shop.example"
              and http.request.uri.path eq "/__waf-canary"
              and http.request.method eq "GET"
              and http.request.headers["x-acme-waf-canary"][0] eq "rollout-2026-07-14")
Action :      Log

Pour un véritable faux positif, corrélez d'abord un Security Event assaini avec le responsable de la route et le résultat côté origine. Créez ensuite l'exception de managed rule la plus étroite possible : host exact, chemin exact, méthode, condition d'intégration vérifiée, et uniquement la règle impliquée lorsque Cloudflare le permet. Cloudflare documente que les exceptions s'exécutent dans l'ordre de la liste au sein de http_request_firewall_managed ; un skip n'affecte que les règles d'exécution managées placées après lui. N'utilisez pas une règle skip personnalisée pour masquer des produits de sécurité sans rapport.

Étape 1 : déployer les règles WAF managées avec un plan d'observation

Les règles WAF managées sont des protections préconfigurées que Cloudflare met à jour pour traiter les techniques d'attaque et vulnérabilités courantes. Commencez par examiner les rulesets actuellement disponibles, leurs valeurs par défaut et la disponibilité selon le plan dans la documentation Managed Rules. Notez qu'une mise à jour de managed ruleset peut affecter le trafic de production après le déploiement initial ; la responsabilité et la surveillance continue font partie de la configuration.

Pour le déploiement initial :

1. Définissez les hosts protégés et les routes à forte valeur, notamment les chemins de connexion, d'administration, d'upload et d'API.
2. Confirmez que chaque client critique peut être testé : navigateur, application mobile, client API server-to-server, expéditeur de webhook et moniteur synthétique.
3. Commencez en staging ou dans un périmètre de production contraint lorsque la conception du service le permet.
4. Observez les événements de sécurité et les erreurs applicatives sur une fenêtre de trafic représentative avant d'ajouter des exceptions ou de modifier des actions.
5. Examinez une règle correspondante avec le contexte de requête et les éléments de preuve de l'origine ; ne supprimez pas une règle sur le seul nombre d'alertes.

Les règles WAF managées n'inspectent le corps des requêtes que jusqu'à une taille limite, et cette limite n'est pas uniforme : Cloudflare documente une valeur par défaut de 1 Mo sur les zones Free, et de 128 Ko par défaut sur Enterprise et les autres zones payantes, les clients des plans payants pouvant demander une augmentation (jusqu'à 1 Mo) auprès du support Cloudflare. Cloudflare est revenu sur cette limite précise aussi récemment qu'en décembre 2025, après qu'une tentative de la relever à 1 Mo partout a provoqué une vague de faux positifs dans le Cloudflare Managed Ruleset et l'OWASP Core Ruleset et a dû être annulée pour les plans payants. Traitez tout chiffre de taille de corps comme une valeur à revérifier dans le changelog actuel, pas comme une constante. Les uploads volumineux, les corps en chunked et les formes de requêtes inhabituelles nécessitent des tests explicites pour cette raison précise : le contenu au-delà de la limite n'est pas inspecté du tout, qu'une règle l'aurait ou non fait correspondre par ailleurs. Cloudflare met aussi à jour en continu ses managed rulesets et leur couverture ; confirmez donc les ID de règle actuels, les actions par défaut et les limites dans la documentation liée plutôt que de traiter une valeur historique comme permanente.

Étape 2 : ajouter les Custom Rules une par une

Créez une Custom Rule uniquement pour un besoin applicatif précis et observé : par exemple, un motif d'exploitation étroit contre un endpoint public, du trafic qui ne devrait jamais atteindre un chemin administratif ou un contrôle d'incident temporaire avec une revue d'expiration. Préférez des propriétés de requête stables telles que le host, le chemin, la méthode et une identité de service validée aux correspondances larges sur User-Agent, la géographie ou l'IP.

Utilisez une règle de test canari qui ne peut correspondre qu'à un host de test dédié et à un en-tête de test aléatoire. Son expression et son action exactes doivent être examinées dans votre workflow habituel de configuration. Utilisez ensuite une requête telle que :

curl -sS -D - -o /dev/null \
  -H 'X-WAF-Test: replace-with-a-random-test-value' \
  https://staging.example.com/__waf-test

Confirmez l'action attendue dans Cloudflare Security Events, la réponse HTTP attendue côté client et l'absence ou présence attendue d'une requête d'origine. Supprimez la règle canari une fois le modèle de déploiement démontré. Ne testez pas un WAF de production en envoyant de véritables payloads d'exploitation, des requêtes destructrices ou du trafic de scan tiers vers une infrastructure partagée.

Pour le canari d'Acme Shop, consignez une requête inoffensive et sa preuve non sensible. La valeur d'en-tête est un marqueur de déploiement, pas un identifiant secret.

curl -sS -D - -o /dev/null \
  -H 'X-Acme-WAF-Canary: rollout-2026-07-14' \
  https://staging.acme-shop.example/__waf-canary

La réponse attendue est un 200 avec un content-type: application/json, et le Security Event correspondant doit afficher l'action log, la règle « Observer le canari WAF d'Acme Shop uniquement », le host staging.acme-shop.example, le chemin /__waf-canary et une requête d'origine effectivement envoyée.

Matrice de validation

Cloudflare Custom Rules utilise le Rules language et les évalue dans l'ordre. La référence Custom Rules actuelle fait autorité pour les champs, actions, quotas et disponibilités selon le plan pris en charge. Utilisez ses instructions dashboard, API ou Terraform selon le système de configuration que votre équipe peut examiner et annuler ; évitez de recopier des libellés dashboard ou une syntaxe de règle depuis un ancien runbook sans vérifier la documentation actuelle.

Le test des règles WAF comme suite de régression reproductible

Une requête canari ponctuelle prouve qu'une règle fonctionne une fois. Un test des règles WAF durable ressemble davantage à une petite suite de régression que l'on rejoue après chaque changement, pas seulement après celui qu'elle a été écrite pour valider, parce que les couches de règles décrites plus haut interagissent entre elles à travers les phases.

Scriptez et rejouez au minimum :

1. La requête canari dédiée (action Log uniquement, host et chemin isolés) confirmée plus haut.
2. Un parcours navigateur légitime complet : connexion, page produit, panier, checkout.
3. Le webhook d'inventaire signé et les chemins de lecture et d'écriture authentifiés de l'API mobile.
4. Une requête juste sous, puis juste au-dessus, du seuil de rate limiting configuré sur la même route — un blocage à ce niveau intervient avant que les Managed Rules, ou une quelconque exception de managed rule, ne soient jamais évaluées ; il a donc besoin de son propre contrôle plutôt que d'être déduit d'un test des Managed Rules.
5. Une tentative de connexion avec un identifiant de test connu comme compromis, si la zone exécute la détection des identifiants compromis de Cloudflare sur la route d'authentification. Vérifiez directement l'en-tête ou l'action attendue ; ne présumez pas que l'ancien ruleset Exposed Credentials Check, désormais déprécié, est toujours ce qui s'exécute, car Cloudflare a migré les nouveaux déploiements vers la détection plus récente.

Conservez cette suite dans le même chemin de configuration revu que les règles elles-mêmes, afin qu'un test des règles WAF en échec bloque un déploiement de la même façon qu'un test applicatif en échec le ferait. Pour Acme Shop, étendez la matrice de validation ci-dessus avec les cas de rate limiting et de vérification d'identifiants avant d'ajouter la prochaine Custom Rule ; une règle qui casse silencieusement l'enveloppe de rate limiting ou l'en-tête de vérification d'identifiants est exactement le type de régression qu'un simple contrôle canari ne détectera pas.

Étape 3 : rendre explicite le comportement des API et non-navigateurs

Un challenge navigateur peut être utile pour un parcours navigateur interactif, mais il est souvent incompatible avec les API JSON, SDK mobiles, webhooks, callbacks de paiement, clients en ligne de commande et contrôles de disponibilité. Pour chaque route protégée, documentez le client attendu et le contrat d'échec :

• Les routes navigateur peuvent avoir une politique de challenge, avec un chemin de récupération et de support accessible.
• Les API machine-to-machine doivent recevoir une réponse de refus prévisible et lisible par machine, et utiliser une authentification, autorisation, validation de schéma et des contrôles de débit robustes.
• Les endpoints webhook et partenaires doivent authentifier cryptographiquement l'expéditeur lorsque cela est pris en charge ; ne vous appuyez pas sur un contrôle orienté navigateur.
• Les intégrations de monitoring et de déploiement nécessitent des conditions d'accès délibérément ciblées et expirantes. Une allowlist IP permanente large ou un skip global est un chemin d'attaque, pas une stratégie d'exception.

Exécutez des tests client approuvés après chaque changement de règle. Vérifiez un parcours navigateur autorisé, une requête API valide, une requête invalide attendue, un test webhook lorsque disponible et une sonde de monitoring. Incluez le code de statut, le type de contenu de réponse, la latence, le résultat applicatif et si la requête a atteint l'origine. Une page 403 ou de challenge n'est pas nécessairement un échec API correct ; le contrat du consommateur détermine ce qui est correct.

Étape 4 : examiner les logs sans créer de fuite de données

Cloudflare Security Events aide à identifier les requêtes sur lesquelles Cloudflare a agi ou qu'il a signalées, et peut être filtré par règle, action, host, chemin et autres dimensions. Utilisez-le pour corréler un changement de règle candidat avec les erreurs applicatives et les rapports client. Toutefois, Cloudflare documente que Security Events peut utiliser des données échantillonnées ; c'est un élément utile pour l'investigation, pas un enregistrement complet de chaque requête. Conservez et corrélez la télémétrie origine, application et SIEM appropriée pour les services critiques.

Les fenêtres de rétention et d'interrogation dépendent elles aussi du plan, et elles sont plus courtes que ne le supposent la plupart des chronologies d'incident :

Les plans payants peuvent exporter jusqu'à 500 événements échantillonnés au format JSON par requête ; Free et Pro ne peuvent pas exporter du tout. Si le responsable de rollback d'Acme Shop a besoin de preuves le jour même pour une revue d'incident qui dépasse la fenêtre de rétention, exporter un lot assaini pendant la fenêtre d'observation de l'Étape 1 est souvent le seul moyen de le conserver.

Traitez les exports d'événements de sécurité, fichiers HAR, logs d'origine et identifiants de trace comme des données opérationnelles sensibles. Ils peuvent contenir des URL avec paramètres de requête, adresses IP client, identifiants, en-têtes ou détails de payload. Appliquez un accès de moindre privilège et des limites de rétention ; masquez tokens, cookies, en-têtes d'autorisation, URL signées, données personnelles et corps de requête avant de partager les éléments de preuve. Utilisez un canal d'incident sécurisé plutôt que de coller des événements bruts dans des tickets ou un chat.

Pendant l'investigation, ne collectez que le minimum nécessaire : plage horaire UTC, hostname, modèle de route plutôt qu'une URL personnelle brute, action, identité de règle ou ruleset, catégorie de client, ID de corrélation de requête lorsque disponible et résultat applicatif assaini. La documentation Security Events de Cloudflare explique les limites de filtrage, d'échantillonnage, de rétention et d'export.

Étape 5 : utiliser des exceptions ciblées, pas des contournements larges

Un faux positif est un élément à examiner, pas une raison automatique de désactiver une protection. Identifiez d'abord la managed rule précise et le plus petit ensemble de requêtes légitimes qui entre en conflit avec elle. Cloudflare recommande une exception ou un ajustement de règle précis plutôt que de désactiver un ruleset entier lorsqu'une seule règle est responsable.

Les exceptions ne s'appliquent qu'aux managed rulesets du WAF : elles ne peuvent pas ignorer les Rate Limiting Rules, le Super Bot Fight Mode, le Browser Integrity Check ou le Zone Lockdown. Pour contourner un de ces produits pour une condition vérifiée, utilisez une Custom Rule avec l'action Skip nommant ce produit précis, avec un périmètre aussi étroit qu'une exception de managed rule ci-dessous — et non une exception de managed rule elle-même.

Une exception doit être aussi étroite que les preuves le permettent :

• Faites correspondre le hostname et le chemin exacts, et incluez la méthode HTTP lorsqu'elle distingue la requête.
• Limitez-la au client authentifié ou à la condition d'intégration vérifiée uniquement lorsque ce signal est fiable.
• Ignorez uniquement la managed rule ou le composant de ruleset impliqué, et non tous les produits de sécurité, lorsqu'un périmètre plus étroit est pris en charge.
• Faites correspondre le niveau de périmètre de l'exception à celui de la règle qu'elle cible : une exception au niveau du compte n'ignore que les règles configurées à ce niveau, et une exception au niveau de la zone n'ignore que les règles de niveau zone. Une exception créée au mauvais niveau paraît correctement configurée et pourtant reste sans effet, car la requête a déjà été mise en correspondance avec la copie de la règle de l'autre niveau.
• Documentez la raison métier, le responsable, la date de création, la date de revue, le cas de test et la condition de suppression.
• Retestez la requête légitime comme une route protégée non liée après avoir placé l'exception dans l'ordre requis.

N'utilisez jamais une exception large pour masquer une intégration défaillante. Corrigez si possible l'encodage de requête, la validation applicative, l'authentification client ou la conception de route sous-jacente. Consultez les conseils Cloudflare de dépannage des managed rules et les conseils sur les exceptions WAF pour le comportement actuel des exceptions et overrides.

Rollback

1. Identifiez la règle, l'override de managed rule ou l'exception nouvelle exacte dans l'enregistrement de changement ; conservez d'abord les éléments d'événement pertinents et assainis.
2. Désactivez ou supprimez uniquement ce changement récent en utilisant le même chemin de configuration examiné que celui qui l'a déployé.
3. Réexécutez les contrôles navigateur, API, webhook et monitoring concernés par le changement, ainsi que la requête canari dédiée si elle reste disponible.
4. Confirmez dans les événements de sécurité et la télémétrie d'origine que le trafic légitime se rétablit et que le rollback n'a pas ouvert un contournement large non voulu.
5. Si une exception de managed rule a causé le problème, restaurez l'ordre et le périmètre antérieurs de l'exception avant d'effectuer un autre changement.

Ne résolvez pas une interruption en désactivant globalement toutes les managed rules ou en créant un skip non restreint, sauf si le responsable d'incident accepte explicitement ce risque temporaire. Si une mitigation d'urgence large est inévitable, limitez-la dans le temps, consignez l'exposition, exigez un second relecteur et créez une tâche de suppression suivie avant de clore l'incident.

Dépannage

Références faisant autorité

• Cloudflare WAF overview
• Cloudflare Managed Rules
• Cloudflare Custom Rules
• Cloudflare Rate Limiting Rules
• Cloudflare Security Events
• Cloudflare managed-rule troubleshooting
• Cloudflare WAF exceptions
• Cloudflare WAF feature interoperability
• Cloudflare leaked credentials detection
• Cloudflare Rules language
• Cloudflare changelog : évolution de la taille maximale du payload WAF (décembre 2025)