Betrugserkennung am Edge: Cloudflare Workers + tracio.ai

Traditionelle Betrugserkennung findet auf der Anwendungsebene statt: Die Anfrage trifft bei Ihrem Server ein, Sie fragen Ihre Betrugserkennungs-API ab, warten auf die Antwort und entscheiden dann, ob Sie zulassen oder blockieren. Dieser Round-Trip fügt jeder Anfrage 50–200ms Latenz hinzu – akzeptabel für Seitenaufrufe, aber schmerzhaft für API-Endpunkte, AJAX-Aufrufe und Echtzeit-Interaktionen.

Was, wenn Sie die Betrugsentscheidung treffen könnten, bevor die Anfrage Ihren Origin-Server erreicht? Genau das ermöglicht Edge Computing, und Cloudflare Workers ist die Plattform, mit der wir dieses Muster demonstrieren.

Die Architektur

Der Aufbau besteht aus drei Komponenten: dem tracio.ai JS SDK (@tracio/sdk), das im Browser läuft, einem Cloudflare Worker, der zwischen dem Client und Ihrem Origin sitzt, und signierten tracio.ai-Webhooks, die die vollständige Signalanalyse an Ihr Backend liefern.

Der Ablauf funktioniert so: Das JS SDK erfasst Gerätesignale und sendet sie während des Seitenaufrufs an tracio.ai, wobei es eine visitorId an den Browser zurückgibt. Ihr Backend empfängt das vollständige Identifikationsergebnis – Bot-Klassifizierung, Smart Signals, Konfidenz – über einen signierten Webhook und schreibt das Verdikt in einen Edge-Cache. Der Browser fügt die visitorId nachfolgenden API-Anfragen hinzu (per Header oder Cookie). Der Cloudflare Worker fängt jede Anfrage ab, schlägt das gecachte Verdikt für diese visitorId nach und trifft in unter 5ms eine Allow/Block-Entscheidung.

Worker-Implementierung

Der Worker unterhält einen leichtgewichtigen Cache jüngster Geräteverifizierungsergebnisse über Cloudflares KV-Storage, der von Ihrem Backend befüllt wird, sobald signierte tracio.ai-Webhooks eintreffen. Wenn eine Anfrage mit einem visitorId-Header eintrifft, prüft der Worker den Cache. Ist das Verdikt gecacht und der Besucher sauber (niedriger Bot-Score, kein VPN, Konfidenz über dem Schwellenwert), wird die Anfrage sofort durchgelassen. Ist noch kein Verdikt gecacht, wendet der Worker Ihre Fallback-Policy an – durchlassen mit einem konservativen Rate-Limit oder Challenge –, bis der webhook-gesteuerte Cache aufgeholt hat.

Die entscheidende Erkenntnis ist, dass der Verifizierungs-Cache proaktiv befüllt wird. Der erste Seitenaufruf löst die Signalerfassung aus und cacht das Ergebnis. Alle nachfolgenden API-Aufrufe dieses Besuchers treffen den Cache – kein Round-Trip zu tracio.ai erforderlich. Die Cache-TTL ist konfigurierbar; wir empfehlen 5 Minuten für Endpunkte mit hoher Sicherheitsanforderung und 30 Minuten für allgemeine Inhalte.

Leistungskennzahlen

Wir haben diese Architektur mit einem Kunden getestet, der 50.000 Anfragen pro Minute über Cloudflare Workers verarbeitet. Ergebnisse:

Cache-Trefferrate: 94% (die meisten Anfragen stammen von Besuchern, die bereits eine Seite geladen haben). Edge-Entscheidungslatenz (Cache-Treffer): 1,2ms Median, 3,8ms p99. Edge-Entscheidungslatenz (Cache-Miss): 45ms Median (inklusive API-Aufruf an tracio.ai). Origin-Latenzeinsparung: 120ms Median pro Anfrage (eliminierte serverseitige Betrugsprüfung).

Die Cache-Trefferrate von 94% bedeutet, dass 94% der Betrugsentscheidungen in unter 4ms am Edge stattfinden, ganz ohne Beteiligung des Origins. Die verbleibenden 6% sind Erstbesuch-Anfragen, die einen vollständigen API-Round-Trip erfordern.

Blockierstrategien

Der Worker unterstützt drei Blockierstrategien, konfigurierbar pro Route:

Hard Block: Gibt für Besucher mit hohem Risiko (Bot-Score > 0.9, bekanntes Automatisierungs-Framework) sofort 403 zurück. Soft Block: Fügt X-Tracio-Risk-Header hinzu und überlässt dem Origin die Entscheidung. Das ist nützlich, wenn Sie für die Entscheidung Kontext auf Anwendungsebene wünschen. Challenge: Leitet verdächtige Besucher (moderater Bot-Score, VPN erkannt) auf eine Challenge-Seite um, die eine zusätzliche Verifizierung verlangt.

Wir empfehlen, in der Produktion mit Soft Blocking zu beginnen, die Risikoverteilung eine Woche lang zu beobachten und dann Hard Blocking für eindeutige Fälle zu aktivieren (bekannte Bots, Headless-Browser, Automatisierung mit hoher Konfidenz).

Kostenanalyse

Die Preisgestaltung von Cloudflare Workers basiert auf Anfragen und Rechenzeit. Bei 50K Anfragen/Minute (2,16 Milliarden/Monat) belaufen sich die Worker-Kosten auf etwa 500 $/Monat. Vergleichen Sie dies mit der Latenzeinsparung: Der Wegfall von 120ms origin-seitiger Betrugsprüfung senkt die CPU-Auslastung des Servers um 15–20%, was in der Rechenleistung typischerweise mehr einspart als die Worker-Kosten.

Der eigentliche Wert liegt in der Betrugsprävention: Bots und betrügerische Anfragen abfangen, bevor sie Origin-Ressourcen, Datenbankverbindungen und nachgelagerte API-Aufrufe verbrauchen. Ein Kunde reduzierte seine Anzahl an Origin-Servern nach Einführung der edge-basierten Betrugserkennung von 12 auf 8 – die Bots, die 30% seiner Rechenleistung verbraucht hatten, erreichten den Origin nie.