Pourquoi le Bot Fight Mode générique pose problème en production

Le Bot Fight Mode (sur les offres Free) et le Super Bot Fight Mode (sur les offres Pro) de Cloudflare fonctionnent comme des interrupteurs globaux. Ils appliquent des CAPTCHAs automatiques avant même l'évaluation de vos règles de sécurité personnalisées.

Ce fonctionnement binaire crée des perturbations majeures :

  • Blocage des requêtes d'API et webhooks : Les passerelles de paiement (Stripe, PayPal, Mollie) ou les outils tiers ne peuvent pas résoudre de CAPTCHAs et sont rejetés en erreur HTTP 403.
  • Faux positifs sur navigateurs sécurisés : Les visiteurs sous Brave, Firefox strict ou derrière des VPN d'entreprise déclenchent fréquemment les heuristiques d'anomalie de Cloudflare.
  • Absence de liste d'exclusion granulaire : Sur le plan Free, il est impossible d'exclure un chemin d'URL spécifique du Bot Fight Mode ; l'option s'applique à tout le domaine ou à rien.
  • Scrapers avancés non bloqués : Les bots utilisant des navigateurs headless modernes contournent souvent les CAPTCHAs basiques tandis que les clients mobiles légitimes restent bloqués.

Le résultat est un système qui se déclenche sur les mauvaises requêtes : un webhook légitime est rejeté parce qu'il est techniquement automatisé, tandis qu'un vrai client sur un navigateur respectueux de la vie privée résout le captcha et se le fait reposer sans jamais accéder au site. Le même problème de granularité se pose quand l'objectif est de filtrer les scrapers IA, comme expliqué dans notre guide bloquer les crawlers IA sans bloquer Googlebot.

La méthode efficace : des règles de sécurité sur mesure

Plutôt qu'un bouton aveugle, une protection efficace contre les bots repose sur la combinaison de règles ciblées :

  • Rate Limiting par point d'entrée : Plafonner les requêtes sur les endpoints critiques (recherche, formulaires, authentification) sans pénaliser la navigation normale.
  • Vérification formelle des bots d'indexation : Utiliser le champ cf.client.bot pour autoriser les vrais moteurs de recherche et bloquer les usurpations de User-Agent.
  • Managed Challenge au lieu du CAPTCHA JavaScript bloquant : Privilégier les Managed Challenges transparents (Turnstile) qui préservent l'expérience utilisateur.
  • Isolation des routes API : Créer des règles de contournement sécurisées pour les endpoints techniques et webhooks.

Cette approche ne couvre que le trafic automatisé. Quand les requêtes bloquées proviennent d'un navigateur normal sur un formulaire ou un tunnel de paiement, le coupable est généralement une des signatures des Managed Rules plutôt que la détection de bots, ce qui appelle un correctif différent décrit dans notre guide sur les faux positifs de sécurité sur les inscriptions et paiements.

Corriger un faux positif Bot Fight Mode étape par étape

Voici la séquence exacte pour résoudre un faux positif sur une zone en production sans ouvrir de faille de protection :

  1. Identifier ce qui est réellement bloqué. Dans le dashboard Cloudflare, sélectionnez votre domaine et ouvrez Security > Events. Filtrez sur les actions "Block" et "Managed Challenge" et repérez les entrées dont le service est Bot Fight Mode. Notez le chemin d'URL, le User-Agent et l'ASN de chaque requête concernée. Cette étape sépare un vrai faux positif (un webhook de paiement, un vrai client) du trafic automatisé que vous voulez effectivement stopper.
  2. Désactiver le bouton global sur les offres Free. Allez dans Security > Bots et désactivez le Bot Fight Mode. Dans le plan Free de Cloudflare™, il ne peut pas être restreint à certains chemins ni exempté par des règles personnalisées : tant qu'il reste actif, vos propres règles ne peuvent pas laisser passer le trafic qu'il soumet à un CAPTCHA. Dans le plan Pro, le Super Bot Fight Mode expose des réponses par catégorie (bots vérifiés, automation certain, etc.), vous pouvez donc souvent le conserver en ajustant simplement sa configuration.
  3. Reconstruire une protection ciblée avec une règle de sécurité personnalisée. Dans Security > WAF > Custom rules, créez une règle qui soumet à un CAPTCHA le trafic suspect tout en laissant passer les bots vérifiés et les endpoints de webhooks :
(not cf.client.bot
  and not starts_with(http.request.uri.path, "/api/webhooks/")
  and cf.threat_score ge 30)

Choisissez l'action Managed Challenge. Le champ cf.client.bot correspond aux bots vérifiés par Cloudflare via reverse DNS : les visites de Googlebot et Bingbot ne sont jamais soumises à CAPTCHA. http.request.uri.path isole vos endpoints de webhooks et cf.threat_score garde la règle conservatrice pour ne pas toucher la navigation ordinaire.

  1. Ajouter du Rate Limiting sur les endpoints sensibles. Dans Security > WAF > Rate limiting rules, protégez le login et l'inscription avec une expression de comptage :
(http.request.uri.path eq "/login"
  and http.request.method eq "POST"
  and not cf.client.bot)

Comptez au-delà de 10 requêtes par minute et par IP et appliquez un Block de 10 minutes. Cela stoppe les scripts de force brute et les bots de spam sans pénaliser un humain qui soumet simplement le formulaire deux fois.

  1. Exempter les sources serveur à serveur de confiance. Les passerelles de paiement et les outils de supervision envoient leurs callbacks depuis un petit ensemble de systèmes autonomes. Ajoutez une condition sur ip.src.asnum correspondant à l'ASN de votre fournisseur dans une règle personnalisée ou une règle Skip, pour que leurs requêtes ne soient jamais soumises à CAPTCHA quel que soit leur User-Agent.
  2. Vérifier pendant les 24 à 48 heures suivantes. Revoyez Security > Events le lendemain : les chemins légitimes auparavant bloqués ne doivent plus apparaître, tandis que les requêtes automatisées bloquées doivent toujours être comptabilisées. N'ajustez le seuil cf.threat_score que si le journal montre que la règle est devenue trop permissive ou reste trop stricte.

Les erreurs fréquentes qui maintiennent les faux positifs

  • Désactiver le Bot Fight Mode sans rien mettre à la place. Les plaintes cessent, mais chaque scraper et chaque script de credential stuffing atteint désormais votre origine sans être soumis à un CAPTCHA. Déployez toujours les règles de remplacement avant de couper le bouton.
  • Écrire des règles Skip trop larges. Exempter tous les chemins contenant /api/ paraît sûr, mais l'essentiel des abus passe aussi par des chemins d'API. Limitez chaque exemption à des chemins et des méthodes HTTP précis.
  • Filtrer uniquement sur le User-Agent. N'importe quel script peut envoyer un User-Agent Googlebot. Seul cf.client.bot est vérifié ; un simple filtrage UA ne bloque rien de sérieux et peut bloquer le mauvais visiteur.
  • Laisser des CAPTCHAs sur les endpoints de webhooks. Les services externes ne résolvent jamais de CAPTCHAs. Un webhook soumis à un CAPTCHA échoue en silence et vous découvrez l'intégration cassée des jours plus tard dans un rapport de réconciliation.
  • Régler une fois et ne plus jamais vérifier. Les schémas de trafic évoluent : une règle réglée il y a plusieurs mois peut se mettre à soumettre à un CAPTCHA un nouveau navigateur mobile ou une nouvelle intégration. Une revue mensuelle rapide de Security > Events permet de garder des règles adaptées au trafic réel.

Questions fréquentes

Pourquoi seuls certains visiteurs se font reposer le captcha en boucle ?

Le Bot Fight Mode note chaque requête selon des signaux comportementaux et réseau. Les visiteurs sur des navigateurs grand public avec des IP résidentielles passent généralement sans s'en apercevoir, tandis que les navigateurs axés privacy, les réglages anti-pistage stricts, les VPN d'entreprise et les réseaux mobiles à IP partagée déclenchent les heuristiques. Les utilisateurs qui se plaignent ne l'inventent pas : ils correspondent simplement aux profils que l'heuristique suspecte le plus.

Cela fonctionne-t-il sur une offre Free ou faut-il passer à une offre payante ?

L'essentiel du correctif fonctionne sur Free : les règles de sécurité personnalisées, les Managed Challenges et une dotation gratuite de Rate Limiting sont disponibles. Ce que Free n'offre pas, c'est la possibilité de restreindre ou configurer le Bot Fight Mode lui-même, d'où la recommandation de désactiver le bouton et de reconstruire la protection avec vos propres règles. Une offre Pro apporte une visibilité bot plus fine et la configuration du Super Bot Fight Mode, mais elle n'est pas nécessaire pour éliminer les faux positifs.

Est-il risqué de désactiver le Bot Fight Mode ?

Pas si vous le remplacez d'abord. Les faux positifs disparaissent parce que l'heuristique grossière s'en va, mais l'automatisation malveillante revient tout aussi vite si rien ne la remplace. La séquence ci-dessus existe justement pour conserver un filet de sécurité : les bots vérifiés passent, le trafic suspect reçoit un Managed Challenge, et les endpoints de login et d'inscription restent soumis au Rate Limiting.

En combien de temps le correctif prend-il effet ?

Les changements de règles se propagent au réseau Cloudflare en quelques secondes : les utilisateurs et webhooks bloqués se reconnectent immédiatement. La phase de vérification prend plus de temps : surveillez Security > Events pendant 24 à 48 heures pour confirmer que les nouvelles règles continuent d'attraper le trafic automatisé que l'ancien bouton filtrait. Si un prestataire de paiement est encore rejeté passé ce délai, identifiez son ASN exact et ajoutez-le à l'exemption.

Besoin d'aide pour régler votre protection anti-bots sans bloquer vos clients ?

CF Garage analyse vos événements de sécurité et met en place les règles de sécurité et de Rate Limiting adaptées à votre site web. Tarif fixe, résultat garanti.

Voir nos offres

Ressources et guides complémentaires