En bref. Cloudflare évalue les règles WAF personnalisées dans l’ordre : une exception Skip doit donc précéder une règle à action terminale et couvrir les règles ou les phases qu’elle doit contourner.

Définition : Cloudflare évalue les règles personnalisées du pare-feu applicatif web (web application firewall, WAF) dans l’ordre configuré. Lorsqu’une requête correspond à une règle dont l’action est terminale, comme Block ou Managed Challenge, l’évaluation des règles et des phases de sécurité suivantes s’arrête pour cette requête.

Points clés

En octobre 2026, Cloudflare documente le fonctionnement suivant :

La documentation des règles personnalisées de Cloudflare indique qu’une règle qui bloque une requête empêche les règles suivantes de s’exécuter pour cette même requête.
La référence des actions classe Managed Challenge parmi les actions terminales et Log parmi les actions non terminales.
Le guide d’interopérabilité des fonctions de sécurité place les règles personnalisées avant les règles de limitation du débit (rate limiting) et les règles gérées (Managed Rules).
La référence des options de l’action Skip distingue le contournement des règles restantes du jeu de règles courant de celui de toutes les règles personnalisées restantes dans la phase courante.

Qu’est-ce qui détermine la première règle exécutée ?

Une règle associe une expression, qui définit les critères de correspondance, à une action, qui définit ce qui se produit lorsqu’une requête correspond à la règle. La présentation des règles personnalisées de Cloudflare précise que ces règles s’exécutent dans l’ordre. Un jeu de règles (ruleset) regroupe des règles ; une phase est une étape du traitement des requêtes pendant laquelle des jeux de règles s’exécutent.

Le guide d’interopérabilité de Cloudflare précise qu’au sein de chaque phase, les jeux de règles du compte s’exécutent avant ceux de la zone. Les règles personnalisées s’exécutent dans http_request_firewall_custom, suivies de la limitation du débit dans http_ratelimit, des règles gérées dans http_request_firewall_managed, puis de Super Bot Fight Mode dans http_request_sbfm. Déplacer une règle de zone au sein de son jeu de règles modifie sa position locale dans cette séquence plus large.

Quelles actions arrêtent l’évaluation ?

La référence des actions de Cloudflare appelle « actions terminales » (terminating actions) les actions qui arrêtent l’évaluation des règles restantes. Block refuse l’accès au site. Managed Challenge est également une action terminale : une règle qui impose une vérification (challenge) peut donc empêcher l’exécution d’une règle personnalisée située après elle.

Log consigne les requêtes correspondantes et laisse l’évaluation se poursuivre. La même référence réserve Log aux offres Enterprise et recommande cette action pour valider les règles avant d’appliquer une action plus sévère. L’effet d’une règle à laquelle correspond une requête dépend donc de son action et de sa position : la correspondance seule ne met pas fin à l’évaluation.

Où placer une exception Skip ?

Une exception Skip doit s’exécuter avant la règle de blocage qu’elle doit contourner. Ce placement découle de l’ordre d’évaluation documenté par Cloudflare : une requête bloquée en amont n’atteint jamais l’exception.

L’exception doit aussi avoir la portée appropriée. La référence des options de l’action Skip de Cloudflare indique que All remaining custom rules permet d’ignorer les règles restantes du jeu de règles courant. L’option All remaining custom rules in this phase, disponible au niveau de la zone, couvre également les règles des jeux de règles personnalisés exécutés plus tard dans cette phase.

Le contournement des phases de sécurité suivantes se configure séparément. La même référence mentionne la limitation du débit, Super Bot Fight Mode et les règles gérées du WAF parmi les phases concernées. Une règle Skip configurée uniquement pour les règles gérées laisse donc les règles personnalisées suivantes soumises à l’évaluation.

Comment modifier et vérifier la position d’une règle ?

La documentation de l’API de mise à jour des règles de Cloudflare prévoit un objet position dans une requête PATCH. Envoyer uniquement cet objet déplace une règle existante tout en conservant sa définition. Ce corps de requête place la règle en tête de son jeu de règles :

{
  "position": {
    "before": ""
  }
}

La même API accepte aussi after ou index ; un seul champ de positionnement peut être utilisé à la fois. Pour les requêtes bloquées, les instructions de dépannage de l’interopérabilité de Cloudflare orientent les administrateurs vers les événements de sécurité (Security Events) et leur champ Service pour identifier le produit qui a appliqué une action.

Termes associés

Questions fréquentes

Une nouvelle règle ajoutée par l’API s’exécute-t-elle automatiquement en premier ?

Non. La documentation de l’API d’ajout de règles de Cloudflare indique que les nouvelles règles sont ajoutées par défaut à la fin de la liste existante. Vous pouvez fournir un objet position pour choisir un autre emplacement.

Une règle Skip placée plus loin peut-elle annuler un blocage Block antérieur ?

Non. La documentation des règles personnalisées de Cloudflare indique que les règles suivantes ne s’exécutent pas lorsqu’une règle précédente bloque la requête. Placez votre exception avant la règle Block concernée.

Puis-je vérifier si une requête correspond à ma règle Skip ?

La documentation des options de l’action Skip de Cloudflare propose l’option Log matching requests. Si vous la désactivez, les requêtes correspondantes n’apparaissent pas dans Security Events ; par défaut, l’API active cette option pour les règles Skip personnalisées.

Sources

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO

Dans quel ordre Cloudflare évalue-t-il les règles WAF personnalisées ?