Un développeur SaaS a découvert qu'en activant le Bot Fight Mode de Cloudflare pour tous les domaines de son compte, il avait paralysé le trafic API pendant un mois entier, empêchant ses clients payants d'utiliser les fonctionnalités principales de son produit.

Le problème est apparu lorsque le développeur a remarqué un aplatissement soudain des métriques d'utilisation. Les nouvelles inscriptions continuaient, mais les sessions actives ne progressaient plus. Après des semaines de réécriture de code et de débogage, un simple paramètre de sécurité s'est avéré être le coupable : le Bot Fight Mode de Cloudflare étiquetait le propre point de terminaison AWS Lambda du SaaS comme un bot malveillant et le bloquait.

Comment un seul paramètre a cassé tout un service

La pile technologique du développeur reposait sur des appels de serveur à serveur. Une fonction Lambda interne envoyait régulièrement des données vers le domaine public du SaaS, un modèle courant dans les architectures de microservices modernes. Le Bot Fight Mode met au défi ou bloque les requêtes qui ressemblent à des scrapers automatisés, protégeant ainsi les sites axés sur le contenu contre la collecte de données.

Lorsque le mode a été activé sur toutes les zones, Cloudflare a traité la requête sortante de la fonction Lambda comme un autre client automatisé. La requête n'a jamais atteint l'application et, comme le blocage s'est produit à l'edge, les outils de surveillance du SaaS n'ont vu aucune erreur – le trafic avait simplement disparu. L'utilisation du CPU du développeur sur Cloudflare Workers a grimpé en flèche, l'amenant à suspecter un scraper externe plutôt que son propre backend.

Ce n'est qu'en fouillant dans les journaux de Cloudflare qu'il a vu des entrées de blocage par le « Bot Fight Mode » correspondant à la plage d'adresses IP de la fonction Lambda. Il a désactivé la fonctionnalité pour les zones concernées, et le trafic API a repris, ramenant les métriques d'utilisation à la normale.

Pourquoi cette erreur est cruciale pour les opérateurs SaaS

  • Les produits centrés sur les API nécessitent des canaux serveur à serveur ouverts. Le Bot Fight Mode part du principe que le trafic principal provient de requêtes de navigateurs humains pour du HTML, des images ou des ressources statiques. Les plateformes SaaS qui exposent des API, des webhooks ou des rappels (callbacks) internes peuvent être bridées ou bloquées sans qu'un code d'erreur visible n'atteigne la couche applicative.
  • Les paramètres de sécurité globaux s'adaptent rarement à toutes les charges de travail. Appliquer une configuration Cloudflare unique à tous les domaines revient à traiter chaque site comme s'il partageait le même modèle de menace. Les sites de contenu, les forums et les back-ends SaaS ont des exigences de sécurité très différentes.
  • Les échecs silencieux rongent le chiffre d'affaires. Le système d'alerte du développeur ne s'est pas déclenché car les requêtes bloquées n'ont jamais atteint l'application. Seule une baisse des métriques d'engagement des utilisateurs a laissé présager le problème. Sans une revue proactive des journaux au niveau de l'edge, des problèmes similaires peuvent persister sans être détectés.

Ce que les développeurs peuvent faire pour éviter le même sort

  1. Auditez le profil de trafic de chaque zone. Avant d'activer le Bot Fight Mode, listez les types de requêtes que votre domaine attend : navigateurs humains, appels API, rappels de webhooks ou appels de services internes. Si certains sont essentiels à la fonctionnalité de base, traitez la zone comme « API-first » et maintenez les paramètres de mitigation des bots au minimum.
  2. Testez les changements dans un environnement de staging. Cloudflare vous permet d'appliquer des paramètres à un seul sous-domaine ou à une zone de test. Vérifiez que l'automatisation légitime fonctionne toujours avant de déployer le changement globalement.
  3. Surveillez les journaux au niveau de l'edge dans le cadre de votre pile d'observabilité. Transférez les journaux du pare-feu et de la mitigation des bots de Cloudflare vers un SIEM, Loki ou tout autre service d'agrégation. Corrélez les pics de requêtes bloquées avec les baisses de métriques applicatives pour détecter rapidement les échecs silencieux.
  4. Rendez les paramètres de sécurité réversibles. Gardez un plan de rollback documenté. Si une nouvelle règle provoque un comportement inattendu, désactivez-la d'abord et confirmez le changement avant d'investir du temps dans des solutions de contournement dans le code.
  5. Posez la bonne question. Au lieu de demander « comment puis-je arrêter les scrapers ? », demandez-vous « cet outil résout-il le problème spécifique que je rencontre ? ». Une fonctionnalité de sécurité qui bloque les scrapers n'est peut-être pas la réponse appropriée pour un SaaS qui nécessite un accès API ouvert.

Une perspective plus large

Le Bot Fight Mode reste précieux pour les sites qui doivent protéger leur contenu statique contre des crawlers agressifs. Son inconvénient est son incapacité à différencier un scraper hostile d'un client automatisé légitime qui suit les mêmes modèles HTTP.

À retenir

Lorsque vous gérez plusieurs domaines sous un seul compte Cloudflare, traitez chacun d'eux comme une zone de sécurité distincte. N'activez le Bot Fight Mode que là où le trafic est purement humain ; pour les charges de travail SaaS intensives en API, laissez le paramètre désactivé ou affinez-le avec des règles de pare-feu personnalisées. Un seul clic peut réduire le trafic légitime au silence aussi efficacement qu'il peut arrêter un scraper.