Rilevamento delle frodi all'edge: Cloudflare Workers + tracio.ai

Il rilevamento tradizionale delle frodi avviene a livello applicativo: la richiesta arriva al suo server, interroga la sua API di rilevamento delle frodi, attende la risposta e poi decide se consentire o bloccare. Questa andata e ritorno aggiunge 50-200ms di latenza a ogni richiesta — accettabile per i caricamenti di pagina, ma penoso per gli endpoint API, le chiamate AJAX e le interazioni in tempo reale.

E se potesse prendere la decisione antifrode prima che la richiesta raggiunga il suo server di origine? È ciò che abilita l'edge computing, e Cloudflare Workers è la piattaforma che usiamo per dimostrare questo pattern.

L'architettura

La configurazione ha tre componenti: l'SDK JS di tracio.ai (@tracio/sdk) in esecuzione nel browser, un Cloudflare Worker posizionato tra il client e la sua origine, e i webhook firmati di tracio.ai che consegnano l'analisi completa dei segnali al suo backend.

Il flusso funziona così: l'SDK JS raccoglie i segnali del dispositivo e li invia a tracio.ai durante il caricamento della pagina, restituendo un visitorId al browser. Il suo backend riceve il risultato completo dell'identificazione — classificazione dei bot, smart signals, confidenza — tramite un webhook firmato e scrive il verdetto in una cache all'edge. Il browser include il visitorId nelle richieste API successive (tramite header o cookie). Il Cloudflare Worker intercetta ogni richiesta, cerca il verdetto in cache per quel visitorId e prende una decisione di consenso/blocco in meno di 5ms.

Implementazione del Worker

Il Worker mantiene una cache leggera dei risultati di verifica recenti dei dispositivi usando lo storage KV di Cloudflare, popolata dal suo backend man mano che arrivano i webhook firmati di tracio.ai. Quando arriva una richiesta con un header visitorId, il Worker controlla la cache. Se il verdetto è in cache e il visitatore è pulito (basso punteggio bot, nessuna VPN, confidenza superiore alla soglia), la richiesta passa immediatamente. Se non c'è ancora alcun verdetto in cache, il Worker applica la sua policy di fallback — passaggio con un rate limit conservativo, oppure challenge — finché la cache alimentata dai webhook non si aggiorna.

L'intuizione critica è che la cache di verifica viene popolata in modo proattivo. Il primo caricamento di pagina attiva la raccolta dei segnali e mette in cache il risultato. Tutte le chiamate API successive di quel visitatore colpiscono la cache — nessuna andata e ritorno verso tracio.ai necessaria. Il TTL della cache è configurabile; raccomandiamo 5 minuti per gli endpoint ad alta sicurezza e 30 minuti per i contenuti generali.

Numeri sulle prestazioni

Abbiamo eseguito un benchmark di questa architettura con un cliente che elabora 50.000 richieste al minuto attraverso Cloudflare Workers. Risultati:

Tasso di cache hit: 94% (la maggior parte delle richieste proviene da visitatori che hanno già caricato una pagina). Latenza della decisione all'edge (cache hit): 1,2ms mediani, 3,8ms p99. Latenza della decisione all'edge (cache miss): 45ms mediani (include la chiamata API a tracio.ai). Risparmio di latenza dell'origine: 120ms mediani per richiesta (controllo antifrode lato server eliminato).

Il tasso di cache hit del 94% significa che il 94% delle decisioni antifrode avviene in meno di 4ms all'edge, senza alcun coinvolgimento dell'origine. Il restante 6% sono richieste di prima visita che richiedono una completa andata e ritorno all'API.

Strategie di blocco

Il Worker supporta tre strategie di blocco, configurabili per rotta:

Blocco rigido: restituire 403 immediatamente per i visitatori ad alto rischio (punteggio bot > 0,9, framework di automazione noto). Blocco morbido: aggiungere header X-Tracio-Risk e lasciare decidere l'origine. Questo è utile quando si desidera un contesto a livello applicativo per la decisione. Challenge: reindirizzare i visitatori sospetti (punteggio bot moderato, VPN rilevata) a una pagina di challenge che richiede una verifica aggiuntiva.

Raccomandiamo di iniziare con il blocco morbido in produzione, monitorare la distribuzione del rischio per una settimana e poi abilitare il blocco rigido per i casi chiari e netti (bot noti, browser headless, automazione ad alta confidenza).

Analisi dei costi

Il prezzo di Cloudflare Workers si basa sulle richieste e sul tempo di calcolo. A 50K richieste/minuto (2,16 miliardi/mese), il costo del Worker è di circa $500/mese. Lo confronti con il risparmio di latenza: eliminare 120ms di controllo antifrode lato origine riduce l'utilizzo della CPU del server del 15-20%, il che tipicamente fa risparmiare in calcolo più del costo del Worker.

Il valore reale è nella prevenzione delle frodi: intercettare bot e richieste fraudolente prima che consumino risorse dell'origine, connessioni al database e chiamate API a valle. Un cliente ha ridotto il numero dei propri server di origine da 12 a 8 dopo aver implementato il rilevamento delle frodi all'edge — i bot che consumavano il 30% del loro calcolo non raggiungevano mai l'origine.