Ein SaaS-Entwickler stellte fest, dass das Aktivieren des Cloudflare Bot Fight Mode für jede Domain in seinem Account den API-Verkehr für einen ganzen Monat zum Erliegen brachte, wodurch zahlende Kunden die Kernfunktionen seines Produkts nicht mehr nutzen konnten.

Das Problem trat auf, als der Entwickler eine plötzliche Abflachung der Nutzungsmetriken bemerkte. Neue Registrierungen kamen zwar weiterhin rein, aber die Anzahl der aktiven Sitzungen hörte auf zu wachsen. Nach Wochen voller Code-Umstellungen und Debugging stellte sich heraus, dass ein einziger Sicherheits-Schalter der Schuldige war: Der Bot Fight Mode von Cloudflare stufte den eigenen AWS Lambda-Endpunkt des SaaS als bösartigen Bot ein und blockierte ihn.

Wie eine einzige Einstellung einen kompletten Service lahmlegte

Der Stack des Entwicklers basierte auf Server-zu-Server-Aufrufen. Eine interne Lambda-Funktion sendete regelmäßig Daten an die öffentliche Domain des SaaS zurück – ein Muster, das in modernen Microservice-Architekturen üblich ist. Der Bot Fight Mode fordert Anfragen, die wie automatisierte Scraper aussehen, heraus oder blockiert sie, um inhaltsgetriebene Websites vor Data Harvesting zu schützen.

Als der Modus für alle Zonen aktiviert wurde, behandelte Cloudflare die ausgehende Anfrage der Lambda-Funktion wie einen weiteren automatisierten Client. Die Anfrage erreichte die Anwendung nie, und da die Blockierung am Edge erfolgte, zeigten die Monitoring-Tools des SaaS keinen Fehler an – der Datenverkehr verschwand einfach. Die CPU-Auslastung des Entwicklers auf Cloudflare Workers schoss in die Höhe, was ihn dazu veranlasste, einen externen Scraper statt seines eigenen Backends zu vermuten.

Erst nachdem er die Cloudflare-Logs analysiert hatte, sah er Einträge, in denen der „Bot Fight Mode“ Anfragen blockiert hatte, die mit dem IP-Bereich der Lambda-Funktion übereinstimmten. Er deaktivierte die Funktion für die betroffenen Zonen, woraufhin der API-Verkehr wieder aufgenommen wurde und die Nutzungsmetriken sich normalisierten.

Warum dieser Fehler für SaaS-Betreiber wichtig ist

  • API-zentrierte Produkte benötigen offene Server-zu-Server-Kanäle. Der Bot Fight Mode geht davon aus, dass der Hauptverkehr aus Anfragen menschlicher Browser nach HTML, Bildern oder statischen Assets besteht. SaaS-Plattformen, die APIs, Webhooks oder interne Callbacks bereitstellen, können gedrosselt oder blockiert werden, ohne dass ein sichtbarer Fehlercode die Anwendungsebene erreicht.
  • Globale Sicherheitseinstellungen passen selten zu jeder Workload. Die Anwendung einer einzigen Cloudflare-Konfiguration auf alle Domains behandelt jede Website so, als ob sie dasselbe Bedrohungsmodell teilen würde. Inhaltsbasierte Websites, Foren und SaaS-Backends haben sehr unterschiedliche Sicherheitsanforderungen.
  • Stille Fehler fressen Umsatz. Das Alerting-System des Entwicklers schlug nicht an, da die blockierten Anfragen die Anwendung nie erreichten. Nur ein Rückgang der User-Engagement-Metriken deutete auf das Problem hin. Ohne proaktive Log-Analysen auf Edge-Ebene können ähnliche Probleme unbemerkt bestehen bleiben.

Was Entwickler tun können, um das gleiche Schicksal zu vermeiden

  1. Auditieren Sie das Traffic-Profil jeder Zone. Bevor Sie den Bot Fight Mode aktivieren, listen Sie die Anfragetypen auf, die Ihre Domain erwartet: menschliche Browser, API-Aufrufe, Webhook-Callbacks oder interne Service-Aufrufe. Wenn davon etwas für die Kernfunktionalität essenziell ist, behandeln Sie die Zone als „API-first“ und halten Sie die Bot-Mitigation-Einstellungen minimal.
  2. Testen Sie Änderungen in einer Staging-Umgebung. Cloudflare ermöglicht es Ihnen, Einstellungen auf eine einzelne Subdomain oder eine Staging-Zone anzuwenden. Überprüfen Sie, ob legitime Automatisierungen weiterhin funktionieren, bevor Sie die Änderung global ausrollen.
  3. Überwachen Sie Logs auf Edge-Ebene als Teil Ihres Observability-Stacks. Streamen Sie die Firewall- und Bot-Mitigation-Logs von Cloudflare an ein SIEM, Loki oder einen anderen Aggregationsdienst. Korrelieren Sie Spitzen bei blockierten Anfragen mit Rückgängen in den Anwendungsmetriken, um stille Fehler frühzeitig zu erkennen.
  4. Machen Sie Sicherheitseinstellungen umkehrbar. Halten Sie einen dokumentierten Rollback-Plan bereit. Wenn eine neue Regel unerwartetes Verhalten verursacht, deaktivieren Sie sie zuerst und bestätigen Sie die Änderung, bevor Sie Zeit in Code-Workarounds investieren.
  5. Stellen Sie die richtige Frage. Anstatt zu fragen „Wie kann ich Scraper stoppen?“, fragen Sie: „Löst dieses Tool das spezifische Problem, das ich sehe?“ Eine Sicherheitsfunktion, die Scraper blockiert, ist möglicherweise nicht die richtige Antwort für ein SaaS, das einen offenen API-Zugriff benötigt.

Die breitere Perspektive

Der Bot Fight Mode bleibt wertvoll für Websites, die statische Inhalte vor aggressiven Crawlern schützen müssen. Sein Nachteil ist die Unfähigkeit, zwischen einem feindseligen Scraper und einem legitimen automatisierten Client zu unterscheiden, der dieselben HTTP-Muster verwendet.

Fazit

Wenn Sie mehrere Domains unter einem einzigen Cloudflare-Account verwalten, behandeln Sie jede einzelne als eine eigene Sicherheitszone. Aktivieren Sie den Bot Fight Mode nur dort, wo der Datenverkehr rein menschlich gesteuert ist; halten Sie ihn bei API-lastigen SaaS-Workloads deaktiviert oder konfigurieren Sie ihn mit benutzerdefinierten Firewall-Regeln fein. Ein einziger Klick kann legitimen Datenverkehr genauso effektiv zum Schweigen bringen, wie er einen Scraper stoppen kann.