Wykrywanie fraudu na brzegu sieci: Cloudflare Workers + tracio.ai

Tradycyjne wykrywanie fraudu odbywa się w warstwie aplikacji: żądanie dociera do Twojego serwera, odpytujesz API do wykrywania fraudu, czekasz na odpowiedź, a następnie decydujesz, czy przepuścić, czy zablokować. Ten round-trip dodaje 50–200 ms opóźnienia do każdego żądania — akceptowalne przy ładowaniu stron, ale uciążliwe dla endpointów API, wywołań AJAX i interakcji w czasie rzeczywistym.

A gdyby można było podjąć decyzję o fraudzie, zanim żądanie dotrze do serwera origin? To właśnie umożliwia edge computing, a Cloudflare Workers to platforma, na której demonstrujemy ten wzorzec.

Architektura

Konfiguracja składa się z trzech komponentów: JS SDK tracio.ai (@tracio/sdk) działającego w przeglądarce, Cloudflare Workera umieszczonego między klientem a Twoim origin oraz podpisanych webhooków tracio.ai dostarczających pełną analizę sygnałów do Twojego backendu.

Przepływ wygląda tak: JS SDK zbiera sygnały urządzenia i wysyła je do tracio.ai podczas ładowania strony, zwracając przeglądarce visitorId. Twój backend otrzymuje pełny wynik identyfikacji — klasyfikację bota, smart signals, poziom pewności — przez podpisany webhook i zapisuje werdykt do cache na brzegu sieci. Przeglądarka dołącza visitorId do kolejnych żądań API (przez nagłówek lub cookie). Cloudflare Worker przechwytuje każde żądanie, sprawdza zapisany w cache werdykt dla danego visitorId i podejmuje decyzję allow/block w mniej niż 5 ms.

Implementacja Workera

Worker utrzymuje lekki cache niedawnych wyników weryfikacji urządzeń, korzystając z magazynu KV Cloudflare, zapełniany przez Twój backend w miarę napływania podpisanych webhooków tracio.ai. Gdy żądanie dociera z nagłówkiem visitorId, Worker sprawdza cache. Jeśli werdykt jest w cache, a odwiedzający jest czysty (niski bot score, brak VPN, poziom pewności powyżej progu), żądanie przechodzi natychmiast. Jeśli werdykt nie jest jeszcze w cache, Worker stosuje Twoją politykę awaryjną — przepuszczenie z zachowawczym rate limitem albo challenge — dopóki cache zasilany webhookami nie zostanie zaktualizowany.

Kluczowy wniosek jest taki, że cache weryfikacji zapełniany jest proaktywnie. Pierwsze ładowanie strony uruchamia zbieranie sygnałów i zapisuje wynik w cache. Wszystkie kolejne wywołania API od tego odwiedzającego trafiają do cache — bez konieczności round-tripu do tracio.ai. Cache TTL jest konfigurowalny; zalecamy 5 minut dla endpointów o wysokim poziomie bezpieczeństwa i 30 minut dla treści ogólnych.

Liczby wydajnościowe

Przeprowadziliśmy testy tej architektury z klientem przetwarzającym 50 000 żądań na minutę przez Cloudflare Workers. Wyniki:

Cache hit rate: 94% (większość żądań pochodzi od odwiedzających, którzy już załadowali stronę). Opóźnienie decyzji na brzegu sieci (cache hit): mediana 1,2 ms, 3,8 ms p99. Opóźnienie decyzji na brzegu sieci (cache miss): mediana 45 ms (obejmuje wywołanie API do tracio.ai). Oszczędność opóźnienia origin: mediana 120 ms na żądanie (wyeliminowana kontrola fraudu po stronie serwera).

Cache hit rate na poziomie 94% oznacza, że 94% decyzji o fraudzie zapada w mniej niż 4 ms na brzegu sieci, bez udziału origin. Pozostałe 6% to żądania z pierwszej wizyty, wymagające pełnego round-tripu do API.

Strategie blokowania

Worker obsługuje trzy strategie blokowania, konfigurowalne per trasa:

Hard block: natychmiastowy zwrot 403 dla odwiedzających o wysokim ryzyku (bot score > 0,9, znany framework automatyzacji). Soft block: dodanie nagłówków X-Tracio-Risk i pozostawienie decyzji origin. Przydatne, gdy chcesz mieć kontekst na poziomie aplikacji przy podejmowaniu decyzji. Challenge: przekierowanie podejrzanych odwiedzających (umiarkowany bot score, wykryty VPN) na stronę challenge wymagającą dodatkowej weryfikacji.

Zalecamy rozpoczęcie od soft blockingu na produkcji, monitorowanie rozkładu ryzyka przez tydzień, a następnie włączenie hard blockingu dla jednoznacznych przypadków (znane boty, przeglądarki headless, automatyzacja z wysokim poziomem pewności).

Analiza kosztów

Cennik Cloudflare Workers opiera się na liczbie żądań i czasie obliczeń. Przy 50 tys. żądań na minutę (2,16 miliarda miesięcznie) koszt Workera to około 500 USD miesięcznie. Porównaj to z oszczędnością opóźnienia: wyeliminowanie 120 ms kontroli fraudu po stronie origin obniża zużycie CPU serwera o 15–20%, co zwykle oszczędza w obliczeniach więcej niż koszt Workera.

Prawdziwa wartość tkwi w zapobieganiu fraudowi: wychwytywaniu botów i fałszywych żądań, zanim zużyją zasoby origin, połączenia z bazą danych i wywołania downstreamowych API. Jeden z klientów zmniejszył liczbę serwerów origin z 12 do 8 po wdrożeniu wykrywania fraudu na brzegu sieci — boty pochłaniające 30% jego mocy obliczeniowej nigdy nie docierały do origin.