Bedrägeridetektering vid edge: Cloudflare Workers + tracio.ai

Traditionell bedrägeridetektering sker på applikationslagret: förfrågan anländer till din server, du frågar ditt bedrägeridetekterings-API, väntar på svaret och avgör sedan om du ska tillåta eller blockera. Denna tur och retur lägger till 50–200 ms latens på varje förfrågan — acceptabelt för sidladdningar, men smärtsamt för API-endpoints, AJAX-anrop och interaktioner i realtid.

Tänk om du kunde fatta bedrägeribeslutet innan förfrågan når din origin-server? Det är vad edge computing möjliggör, och Cloudflare Workers är plattformen vi använder för att demonstrera detta mönster.

Arkitekturen

Uppsättningen har tre komponenter: tracio.ai JS SDK (@tracio/sdk) som körs i webbläsaren, en Cloudflare Worker som sitter mellan klienten och din origin, samt signerade tracio.ai-webhooks som levererar fullständig signalanalys till din backend.

Flödet fungerar så här: JS SDK:et samlar in enhetssignaler och skickar dem till tracio.ai under sidladdningen, och returnerar ett visitorId till webbläsaren. Din backend tar emot det fullständiga identifieringsresultatet — botklassificering, smarta signaler, konfidens — via en signerad webhook och skriver utlåtandet till en edge-cache. Webbläsaren inkluderar visitorId i efterföljande API-förfrågningar (via header eller cookie). Cloudflare Worker fångar upp varje förfrågan, slår upp det cachade utlåtandet för det visitorId:t och fattar ett beslut om tillåt/blockera på under 5 ms.

Worker-implementation

Workern upprätthåller en lättviktig cache med senaste enhetsverifieringsresultat med hjälp av Cloudflares KV-lagring, som fylls på av din backend allteftersom signerade tracio.ai-webhooks anländer. När en förfrågan anländer med en visitorId-header kontrollerar Workern cachen. Om utlåtandet är cachat och besökaren är ren (låg botpoäng, inget VPN, konfidens över tröskelvärdet) släpps förfrågan igenom omedelbart. Om inget utlåtande är cachat ännu tillämpar Workern din reservpolicy — släpp igenom med en konservativ hastighetsbegränsning, eller utmana — tills den webhook-drivna cachen hinner ikapp.

Den avgörande insikten är att verifieringscachen fylls på proaktivt. Den första sidladdningen utlöser signalinsamling och cachar resultatet. Alla efterföljande API-anrop från den besökaren träffar cachen — ingen tur och retur till tracio.ai behövs. Cachens TTL är konfigurerbar; vi rekommenderar 5 minuter för endpoints med höga säkerhetskrav och 30 minuter för allmänt innehåll.

Prestandasiffror

Vi jämförde denna arkitektur med en kund som bearbetar 50 000 förfrågningar per minut genom Cloudflare Workers. Resultat:

Cacheträffkvot: 94 % (de flesta förfrågningar kommer från besökare som redan har laddat en sida). Edge-besluts latens (cacheträff): 1,2 ms median, 3,8 ms p99. Edge-besluts latens (cachemiss): 45 ms median (inkluderar API-anrop till tracio.ai). Origin-latensbesparing: 120 ms median per förfrågan (eliminerad bedrägerikontroll på serversidan).

Cacheträffkvoten på 94 % innebär att 94 % av bedrägeribesluten sker på under 4 ms vid edge, utan någon inblandning av origin. De återstående 6 % är förstagångsförfrågningar som kräver en fullständig API-tur-och-retur.

Blockeringsstrategier

Workern stöder tre blockeringsstrategier, konfigurerbara per rutt:

Hård blockering: Returnera 403 omedelbart för högriskbesökare (botpoäng > 0,9, känt automationsramverk). Mjuk blockering: Lägg till X-Tracio-Risk-headers och låt origin avgöra. Detta är användbart när du vill ha kontext på applikationsnivå för beslutet. Utmaning: Omdirigera misstänkta besökare (måttlig botpoäng, VPN upptäckt) till en utmaningssida som kräver ytterligare verifiering.

Vi rekommenderar att börja med mjuk blockering i produktion, övervaka riskfördelningen under en vecka och sedan aktivera hård blockering för entydiga fall (kända bottar, headless-webbläsare, automation med hög konfidens).

Kostnadsanalys

Prissättningen för Cloudflare Workers baseras på förfrågningar och beräkningstid. Vid 50 000 förfrågningar/minut (2,16 miljarder/månad) är Worker-kostnaden ungefär 500 USD/månad. Jämför detta med latensbesparingarna: att eliminera 120 ms av bedrägerikontroll på origin-sidan minskar serverns CPU-användning med 15–20 %, vilket vanligtvis sparar mer än Worker-kostnaden i beräkning.

Det verkliga värdet ligger i bedrägeriförebyggande: att fånga bottar och bedrägliga förfrågningar innan de förbrukar origin-resurser, databasanslutningar och nedströms API-anrop. En kund minskade antalet origin-servrar från 12 till 8 efter att ha infört edge-baserad bedrägeridetektering — bottarna som förbrukade 30 % av deras beräkningskraft nådde aldrig origin.