Google Cloud Fraud Defense evolve reCAPTCHA contro le frodi

Google Cloud Fraud Defense segna il passaggio di reCAPTCHA da controllo anti-bot a piattaforma di valutazione del rischio digitale: non guarda più solo al clic sospetto, ma all’intero percorso che porta un utente – o un agente AI – dalla registrazione, ad esempio, a un pagamento (si pensi ai siti di e-commerce).

La storia parte da lontano. reCAPTCHA nasce come meccanismo per distinguere persone da software automatizzati; con reCAPTCHA Enterprise, Google aveva già introdotto valutazioni a punteggio, integrazioni API e segnali più ricchi. Ora Google riunisce queste capacità sotto il nome Google Cloud Fraud Defense, con un obiettivo più ampio: proteggere account, transazioni, verifiche SMS, applicazioni mobili, dispositivi IoT e interazioni machine-to-machine.

Google parla di miliardi di interazioni analizzate ogni giorno e di segnali raccolti da milioni di siti protetti. La promessa commerciale costruita attorno al nuovo servizio Cloud Fraud Defense, include una riduzione del 37% degli attacchi bot e un calo del 51% legato al takeover degli account. Sono numeri da leggere con cautela, perché dipendono dai casi d’uso e dal livello di integrazione, ma indicano una tendenza chiara: la difesa antifrode si sposta sempre più vicino ai processi di business.

Cosa cambia da reCAPTCHA a Cloud Fraud Defense

La differenza rispetto al classico utilizzo dei meccanismi CAPTCHA è semplice: Cloud Fraud Defense non verifica soltanto se davanti allo schermo ci sia una persona. Valuta l’intento di una richiesta. In pratica, una registrazione, un login, un’aggiunta al carrello o un pagamento non rappresentano più eventi separati; diventano punti osservabili di una sequenza da esaminare con attenzione.

Il motore di Cloud Fraud Defense assegna punteggi di rischio e codici, utili per decidere come reagire. Un sito può lasciar passare un utente con rischio basso, attivare l’autenticazione multifattore (MFA) nei casi anomali, limitare una sessione, bloccare una richiesta server-to-server o inviare un evento al team antifrode.

Va detto però che la qualità del risultato dipende molto dall’integrazione: Cloud Fraud Defense diventa utile quando riceve e aggrega più segnali relativi a registrazione, autenticazione, dispositivo, sessione, comportamento e transazione.

Bot, scraper e agenti AI: il nuovo confine della fiducia

Google presenta Cloud Fraud Defense come una piattaforma progettata per il nuovo Web agentico.

L’espressione indica un Web in cui software autonomi agiscono per conto degli utenti: assistenti che cercano prodotti, compilano moduli, negoziano passaggi di una transazione o interagiscono con servizi tramite protocolli come Model Context Protocol (MCP) e livelli Agent-to-Agent.

Bloccare tutta l’automazione, come in passato, non basta più, perché una parte di essa potrebbe essere utile e autorizzata. Un assistente AI che compra un biglietto per conto del cliente non ha lo stesso profilo di uno scraper che sottrae cataloghi, di uno scalper che consuma inventario (sistemi automatizzati che prenotano, bloccano o acquistano grandi quantità di prodotti disponibili online per sottrarli agli utenti normali) o di un bot che prova a verificare i dettagli di carte di credito rubate.

Cloud Fraud Defense prova a separare questi casi con un motore adattivo che combina segnali comportamentali, integrità del dispositivo, cronologia delle interazioni e reputazione della richiesta. Non è una distinzione perfetta: gli attaccanti cercheranno di imitare gli agenti legittimi, mentre i servizi dovranno evitare di penalizzare strumenti leciti.

Account takeover e credential stuffing

Uno dei casi d’uso più concreti riguarda la gestione degli attacchi di account takeover. Questi attacchi sfruttano password già esposte in violazioni precedenti e provano combinazioni di credenziali su servizi diversi. Funzionano per un motivo banale: molte persone riutilizzano la stessa password.

La documentazione di Google descrive l’uso della sua nuova soluzione di difesa al fine di individuare tentativi di login anomali, credential stuffing e aggressioni di tipo brute force. Il sistema restituisce un punteggio dedicato e segnali facilmente interpretabili.

Cloud Fraud Defense integra anche funzioni di Password Defense, basate su controlli sicuri rispetto a credenziali compromesse. Google collega questa capacità a Password Checkup, tecnologia usata per confrontare le password con grandi insiemi di credenziali note come già esposte in attacchi precedenti.

Per un’azienda, il valore non consiste solo nel bloccare l’attacco in corso; consiste anche nel ridurre il rischio futuro, inducendo l’utente a cambiare credenziali vulnerabili prima che un criminale le sfrutti davvero.

Account falsi, abuso promozionale e SMS pumping

La creazione automatica di account falsi resta un problema costoso per tanti siti Web e servizi online.

Un attaccante può generare identità fasulle per abusare di bonus di benvenuto, manipolare recensioni, aggirare limiti di utilizzo o preparare campagne successive di frode.

Cloud Fraud Defense affronta questo scenario osservando pattern correlati durante la registrazione: velocità, reputazione dei segnali, qualità del dispositivo, numeri di telefono, indirizzi e sequenze di comportamento.

Un caso specifico è il caso chiamato SMS pumping o (SMS toll fraud): l’attaccante automatizza registrazioni o verifiche telefoniche per generare invii SMS verso numerazioni controllate o costose; il servizio colpito paga il traffico, mentre il criminale monetizza tramite accordi fraudolenti sulla terminazione. La documentazione Google indica SMS Defense, parte integrante del “pacchetto”, come funzione pensata per intercettare numeri sospetti e pattern di registrazione ad alta velocità prima che partano messaggi di autenticazione.

Pagamenti, card testing e modalità solo API

La protezione delle transazioni amplia il raggio d’azione oltre login e registrazione. In fase di checkout su un sito di e-commerce, Cloud Fraud Defense può aiutare a riconoscere test di carte, abuso di promozioni, ordini anomali e comportamenti sospetti. Google cita due modalità di integrazione: JavaScript front-end e modalità solo API, con chiamate dirette da server a server.

La seconda opzione è utile nei flussi in cui non ha senso o non è possibile eseguire codice nel browser. Pensiamo a back-end che ricevono richieste da app native, dispositivi smart, canali partner o agenti autorizzati. La valutazione server-to-server riduce l’attrito visibile per l’utente, ma impone una progettazione accurata.

Dal punto di vista antifrode, il valore non sta nel singolo punteggio isolato. Sta nella correlazione: un pagamento rischioso diventa più leggibile se il sistema conosce la storia recente dell’account, la qualità della registrazione, gli eventi di login, il dispositivo e la reputazione dei segnali di rete.

Prezzi e piani di abbonamento: cosa cambia per chi usa reCAPTCHA, anche in versione free

Google indica che i clienti reCAPTCHA esistenti diventano automaticamente clienti Cloud Fraud Defense e che le chiavi già configurate continuano a funzionare. Non serve quindi una migrazione immediata solo per mantenere operative le integrazioni attuali.

Il modello di prezzo resta legato all’utilizzo: la documentazione Google cita una soglia gratuita di 10.000 controlli mensili per organizzazione; oltre tale limite, serve abilitare la fatturazione.

Dubbi e critiche

Dopo l’annuncio del servizio di Google è venuta a galla un’altra questione rilevante: diversi sviluppatori temono che i sistemi antifrode moderni, come Cloud Fraud Defense, finiscano per penalizzare browser hardened, utenti privacy-oriented o strumenti di automazione legittimi.

Alcuni esperti sottolineano che i motori di scoring comportamentale possono associare un rischio elevato a sessioni prive di telemetria completa, fingerprint inconsueti o configurazioni anti-tracciamento aggressive.

Trasparenza dei modelli e raccolta dei segnali

Una delle riserve più ricorrenti riguarda la crescente dipendenza da sistemi di valutazione opachi. Diversi commentatori hanno osservato che piattaforme come Cloud Fraud Defense prendono decisioni basate su modelli che l’utente finale non può realmente verificare. Alcuni sviluppatori hanno paragonato il problema ai sistemi antifrode bancari: funzionano bene finché non colpiscono un caso legittimo, momento in cui capire il motivo diventa complicato.

Un altro punto discusso riguarda il rischio di centralizzazione. Google già controlla una parte enorme della telemetria Web tramite Chrome, Android, Search, advertising e servizi cloud. Diversi utenti hanno fatto notare che una piattaforma antifrode alimentata da segnali raccolti su scala Google potrebbe rafforzare ulteriormente questa posizione dominante.

Le perplessità sull’efficacia contro minacce sofisticate

Secondo alcuni, autorizzare corsie preferenziali per agenti AI rischierebbe di creare nuove superfici d’abuso. Un attaccante potrebbe cercare di impersonare un agente autorizzato oppure sfruttare credenziali compromesse di agenti legittimi. Il timore è che il Web agentico finisca per aumentare la complessità della fiducia digitale invece di ridurla.

C’è poi una critica molto tecnica legata ai meccanismi di fingerprinting. Per distinguere automazione legittima e malevola, i sistemi antifrode devono inevitabilmente raccogliere una grande quantità di segnali ambientali: rendering grafico, comportamento JavaScript, caratteristiche hardware, pattern di navigazione. Secondo i critici, il risultato potrebbe essere un Web in cui anonimato e compatibilità privacy-first diventano sempre più difficili da ottenere.

Altri hanno messo in dubbio l’efficacia reale contro attaccanti avanzati. La critica non è che Cloud Fraud Defense sia inutile; è che i gruppi criminali più sofisticati ormai usano browser reali, device farm, emulatori avanzati, session hijacking e automazione assistita da esseri umani. In pratica, il rischio è che i controlli più aggressivi colpiscano soprattutto utenti normali o bot “benigni”, mentre gli operatori ben finanziati riescano comunque ad aggirare parte delle difese.