Se conosci reCAPTCHA soprattutto per la casella “Non sono un robot” o per le immagini di semafori e attraversamenti pedonali, oggi ne stai vedendo solo una parte. Le versioni v2 e v3 esistono ancora nelle implementazioni storiche, ma Google ha spostato il prodotto verso un modello più ampio: reCAPTCHA è ora la componente di bot defense della piattaforma Google Cloud Fraud Defense, che estende l’analisi del rischio anche ad account e transazioni.
Questa distinzione è importante perché parlare semplicemente di “reCAPTCHA v2, v3 ed Enterprise” può creare un modello mentale ormai incompleto. Se devi proteggere un nuovo sito, non stai più scegliendo soltanto tra una checkbox e uno score: devi capire che tipo di interazione vuoi verificare, quale rischio vuoi gestire e quale integrazione è adatta al tuo progetto.
Se invece vuoi partire dal concetto generale e capire come si è evoluta questa famiglia di strumenti, trovi anche la nostra guida su cosa sono i CAPTCHA e come funzionano.
Cos’è reCAPTCHA oggi
reCAPTCHA è un sistema di analisi del rischio utilizzato per distinguere le interazioni legittime da quelle potenzialmente automatizzate o abusive. La verifica può essere visibile, come nella classica checkbox, oppure avvenire senza una sfida esplicita, assegnando alla richiesta un punteggio che il sito può utilizzare per decidere come comportarsi.
La differenza rispetto ai CAPTCHA tradizionali è proprio qui: l’obiettivo non è necessariamente costringere ogni persona a superare un test, ma raccogliere segnali sufficienti per valutare il rischio dell’interazione.
Da CAPTCHA anti-bot a sistema di valutazione del rischio
Un CAPTCHA tradizionale funziona soprattutto come barriera: presenta una prova che dovrebbe essere semplice per un essere umano e difficile per un programma automatico.
reCAPTCHA ha progressivamente spostato il problema dalla prova alla valutazione del comportamento e del contesto. Con le integrazioni score-based, per esempio, l’utente può non vedere alcuna sfida. Il sistema assegna invece uno score e lascia all’applicazione la scelta della risposta più appropriata. Google raccomanda attualmente le chiavi score-based per molte nuove integrazioni web.
Questo approccio è più flessibile perché due richieste sospette non devono necessariamente ricevere lo stesso trattamento. Puoi lasciare passare una richiesta a basso rischio, richiedere una verifica aggiuntiva in uno scenario intermedio e bloccare o limitare quella chiaramente anomala.
Perché Google Cloud Fraud Defense cambia il modo di parlare di reCAPTCHA
Google presenta oggi Google Cloud Fraud Defense come una piattaforma unificata contro frodi e abusi. reCAPTCHA rimane al suo interno come componente dedicata soprattutto alla bot defense, mentre altre funzioni affrontano rischi legati agli account e alle transazioni.
Il cambio non è soltanto nominale.
Se proteggi un semplice modulo di contatto, il problema principale può essere lo spam automatizzato. In un ecommerce, invece, lo stesso ecosistema può essere utilizzato per analizzare login sospetti, credential stuffing, utilizzo di password compromesse, abuso degli SMS o tentativi fraudolenti durante il pagamento. Le funzioni disponibili cambiano in base al tier utilizzato.
V2, v3, Enterprise e Fraud Defense non sono quattro versioni equivalenti
Qui conviene fermarsi su una distinzione che evita molta confusione.
reCAPTCHA v2 e reCAPTCHA v3 sono versioni Classic ancora presenti in moltissime integrazioni esistenti. Google continua a documentarne l’uso e permette di migrare chiavi v2 Checkbox, v2 Invisible e v3 verso la nuova infrastruttura.
Google, però, dichiara anche che non è più possibile creare nuove chiavi Classic. Per nuove configurazioni il modello corrente ruota attorno alle chiavi e ai servizi Google Cloud.
“Enterprise”, inoltre, non va più interpretato semplicemente come una quarta versione successiva a v3. Essentials, Premium ed Enterprise sono oggi livelli della piattaforma Fraud Defense con capacità differenti.
Come funziona reCAPTCHA tra browser, token, score e backend
Il punto più importante per capire reCAPTCHA è che la verifica visibile nel browser non dovrebbe essere considerata una decisione di sicurezza completa.
Una normale integrazione coinvolge il client, il servizio Google e il backend del sito.
Cosa succede quando un utente esegue un’azione protetta
Immagina un form di login.
Quando l’utente prova ad accedere, l’integrazione reCAPTCHA raccoglie i segnali previsti per quella specifica implementazione e genera un token associato all’interazione. Nelle configurazioni score-based l’operazione può avvenire senza mostrare una prova all’utente; con una checkbox o una challenge policy può invece essere richiesta un’interazione.
Quel token accompagna la richiesta verso il server.
Il server non dovrebbe limitarsi a controllare che nel form esista un campo reCAPTCHA: deve validare la risposta sul lato backend e applicare la propria logica di sicurezza.
Dal token alla verifica server-side
Nelle implementazioni Classic il backend può verificare il token attraverso siteverify. Google specifica che il token deve essere verificato entro due minuti ed è utilizzabile una sola volta, proprio per limitare i replay.
Nelle integrazioni Google Cloud il modello ruota invece intorno agli assessment. Il backend invia le informazioni necessarie a Fraud Defense e riceve una valutazione che può includere score e ulteriori segnali utili alla decisione.
Questa distinzione è particolarmente importante quando utilizzi WordPress o un plugin: un’estensione che richiede una vecchia site key e una secret key può stare utilizzando ancora il flusso Classic, mentre una nuova integrazione Cloud può funzionare in modo differente.
Score di rischio, reason code e decisione finale
Uno score non significa semplicemente “umano” o “robot”.
Nella documentazione di reCAPTCHA v3, per esempio, il punteggio va da 0,0 a 1,0: valori più alti rappresentano interazioni considerate più probabilmente legittime, mentre valori più bassi indicano maggiore rischio. Google propone 0,5 come punto di partenza nelle integrazioni v3, ma raccomanda di osservare il proprio traffico e adattare le soglie al contesto.
Il punto operativo è proprio questo: 0,5 non è una soglia universale da copiare su ogni sito.
Un ecommerce con account, pagamenti e campagne ad alto traffico ha un profilo di rischio diverso da un piccolo sito vetrina con un modulo contatti.
Perché reCAPTCHA non dovrebbe decidere da solo cosa bloccare
La risposta migliore a una richiesta sospetta non è sempre il blocco.
Su un login potresti richiedere un secondo fattore. Su un commento potresti inviare il contenuto in moderazione. Su un endpoint frequentemente interrogato potresti applicare rate limiting. Su una transazione potresti richiedere ulteriori controlli.
Google stessa suggerisce questo tipo di strategia per le integrazioni score-based: utilizzare il rischio come input della decisione, anziché trasformare automaticamente ogni score basso in un rifiuto.
È anche il motivo per cui reCAPTCHA non sostituisce un Web Application Firewall, l’autenticazione multifattore o le altre misure di sicurezza applicativa.
reCAPTCHA v2: checkbox e Invisible
reCAPTCHA v2 è la famiglia che molti utenti identificano ancora con il prodotto Google.
Le due implementazioni più note sono Checkbox e Invisible.
Come funziona la checkbox “Non sono un robot”
La checkbox presenta all’utente il controllo “Non sono un robot”.
Il click, però, non è l’unica informazione utilizzata dal sistema. In base alla valutazione dell’interazione, reCAPTCHA può considerare sufficiente la verifica oppure presentare una challenge aggiuntiva.
È quindi possibile che due utenti vedano esperienze differenti davanti allo stesso form.
Quando vengono mostrate le sfide con immagini
Le challenge visive entrano in gioco quando la modalità utilizzata richiede un’ulteriore verifica.
È il comportamento che ha reso reCAPTCHA riconoscibile: selezionare determinate immagini o completare un’altra prova per proseguire.
Questa barriera può fermare automazioni poco sofisticate, ma introduce inevitabilmente attrito. La documentazione Google sottolinea inoltre che l’evoluzione della computer vision e dei servizi di CAPTCHA solving ha ridotto il vantaggio delle challenge come strumento universale per distinguere umani e automazioni.
Come funziona reCAPTCHA v2 Invisible
Invisible reCAPTCHA mantiene la logica v2 ma evita di mostrare permanentemente la classica checkbox.
La verifica può essere associata a un pulsante o invocata programmaticamente; quando il sistema ritiene necessaria una challenge, l’utente può comunque doverla completare.
“Invisible”, quindi, non significa che non possa mai comparire una verifica. Significa piuttosto che il controllo non richiede sempre l’interazione iniziale con la checkbox.
Perché la checkbox non è più la scelta consigliata da Google per le nuove integrazioni Cloud
Nella documentazione corrente per la scelta delle nuove chiavi web, Google indica le score-based key come opzione raccomandata e afferma di non raccomandare le checkbox key perché aumentano la friction senza migliorare significativamente l’accuratezza.
Questo non rende inutili tutte le installazioni v2 già esistenti.
Significa però che, se stai progettando oggi una nuova integrazione, non dovresti scegliere la checkbox semplicemente perché è la forma di reCAPTCHA che conosci meglio.
reCAPTCHA v3: protezione score-based senza challenge
reCAPTCHA v3 ha rappresentato il passaggio più evidente dalla logica CAPTCHA alla logica risk-based.
Il sistema assegna uno score alle interazioni senza interrompere normalmente il flusso dell’utente.
Come funziona lo score di reCAPTCHA v3
Con v3 puoi associare la verifica ad azioni come:
- login;
- registrazione;
- reset della password;
- invio di un form;
- acquisto;
- altre interazioni sensibili.
Ogni esecuzione genera un token da inviare al backend, dove vengono controllati validità, score e azione prevista.
Il nome dell’azione conta: Google raccomanda di verificare sul server che l’action restituita corrisponda a quella che ti aspettavi.
Action e soglie: perché non esiste un valore corretto per tutti i siti
Usare la stessa soglia per login, form contatti e checkout è quasi sempre una semplificazione eccessiva.
Un punteggio che consideri sufficientemente affidabile per l’invio di un commento potrebbe non esserlo per modificare la password di un account amministrativo.
Conviene quindi ragionare in termini di:
azione → rischio → conseguenza di un falso positivo → conseguenza di un falso negativo → risposta appropriata.
Più è costoso bloccare erroneamente un utente reale, più ha senso evitare una decisione binaria basata su una soglia arbitraria.
Cosa fare con traffico a rischio invece di limitarsi a bloccarlo
Supponiamo che un login ottenga un punteggio sospetto.
Hai almeno quattro possibilità:
- accettare comunque l’accesso;
- richiedere verifica email;
- richiedere autenticazione multifattore;
- bloccare la richiesta.
Per uno score intermedio la seconda o la terza opzione possono essere migliori del blocco.
Su un form puoi invece applicare una moderazione aggiuntiva. Su una API puoi limitare la frequenza. Su un ecommerce puoi aumentare i controlli prima di accettare un ordine.
Lo score diventa così un segnale della tua politica di rischio, non la politica stessa.
Test, traffico reale e falsi positivi
reCAPTCHA impara anche osservando il traffico reale.
Google avverte che i punteggi ottenuti in staging o poco dopo l’installazione possono essere diversi da quelli che emergeranno in produzione.
Una buona implementazione score-based dovrebbe quindi iniziare con una fase di osservazione, soprattutto se la conseguenza di un falso positivo è seria.
Bloccare immediatamente qualsiasi richiesta sotto una soglia scelta senza dati significa utilizzare un sistema adattivo come se fosse una semplice blacklist.
Da reCAPTCHA Enterprise a Google Cloud Fraud Defense
Il cambiamento più importante da comprendere oggi riguarda l’architettura complessiva del prodotto.
Google descrive Fraud Defense come l’evoluzione di reCAPTCHA e, nella documentazione corrente, reCAPTCHA è una delle componenti della piattaforma, focalizzata sulla core bot defense.
Cosa è successo a reCAPTCHA Enterprise
La vecchia distinzione “reCAPTCHA gratuito contro reCAPTCHA Enterprise” non descrive più bene il catalogo corrente.
Le nuove integrazioni vengono gestite nell’ecosistema Google Cloud e la piattaforma offre livelli Essentials, Premium ed Enterprise. Questo permette a Google di separare la protezione anti-bot di base da funzioni più avanzate per account, transazioni, policy e analisi.
Chi possiede vecchie chiavi Classic non deve necessariamente sostituirle all’istante: Google supporta una procedura di migrazione per v2 Checkbox, v2 Invisible e v3.
Per una nuova implementazione, invece, conviene progettare direttamente sul modello corrente.
Essentials, Premium ed Enterprise sono oggi tier della piattaforma
I tre livelli non indicano tre modalità CAPTCHA.
Indicano livelli commerciali e funzionali differenti.
Essentials comprende la protezione di base e un allowance mensile di assessment. Premium introduce funzioni più avanzate per bot, account, transazioni e policy. Enterprise aggiunge ulteriori capacità analitiche e operative ed è destinato soprattutto a organizzazioni con esigenze e volumi più elevati.
Questo significa che puoi utilizzare una score-based key anche senza essere necessariamente nel tier Enterprise.
Score-based, checkbox, policy-based ed Express: i tipi di chiave correnti
Per il web Google distingue attualmente:
- score-based key, senza challenge obbligatoria;
- checkbox key, con checkbox e challenge non deterministica;
- policy-based challenge key, con challenge determinata dalla politica configurata.
Esistono poi chiavi dedicate ad Android e iOS, integrazioni WAF ed Express key per ambienti in cui non puoi usare normalmente JavaScript o gli SDK mobile.
reCAPTCHA Express può essere usato, per esempio, con API e dispositivi IoT. Google precisa però che, essendo server-side only, dispone di meno segnali client e può quindi avere accuratezza inferiore rispetto alle integrazioni che raccolgono anche informazioni lato client.
Protezione bot, account e transazioni: dove finisce reCAPTCHA e dove inizia Fraud Defense
La separazione più utile è questa:
reCAPTCHA → bot defense
Fraud Defense → bot + account + transaction protection
Nella pratica esistono integrazioni fra questi livelli, ma pensare in questo modo evita di chiedere a un CAPTCHA di risolvere problemi che non appartengono più soltanto alla classificazione umano/bot.
Account defense e Transaction defense: la protezione oltre lo spam
Un bot che invia cento moduli pubblicitari e un criminale che tenta di usare credenziali rubate non rappresentano lo stesso tipo di rischio.
Fraud Defense amplia proprio questa parte del modello.
Account takeover, credential stuffing e Password defense
Account defense utilizza modelli specifici del sito per individuare comportamenti sospetti legati agli account e variazioni anomale nell’attività degli utenti. Può quindi contribuire a riconoscere tentativi di account takeover o gruppi di account con comportamenti correlati.
Password defense affronta invece il problema delle credenziali compromesse: permette di verificare se una combinazione di username e password fornita dall’utente è comparsa in fonti note di credenziali violate.
reCAPTCHA non diventa per questo un sostituto della gestione sicura delle password o dell’autenticazione multifattore. Fornisce segnali aggiuntivi che puoi integrare nella tua risposta.
SMS defense e abuso delle verifiche telefoniche
L’invio di SMS può essere attaccato in modo diverso dal normale spam web.
Gli attacchi di SMS pumping, per esempio, cercano di provocare grandi quantità di messaggi verso numerazioni controllate o costose.
SMS defense produce un risk score prima dell’invio dell’SMS, in modo che l’applicazione possa decidere se procedere o bloccare la richiesta. In questo caso la direzione dello score è diversa da quella del normale score reCAPTCHA: valori più alti indicano maggiore probabilità di SMS toll fraud.
È un buon esempio del motivo per cui non bisogna parlare genericamente di “punteggio reCAPTCHA” senza specificare quale funzione si sta usando.
Transaction defense per carding, chargeback e frodi nei pagamenti
Transaction defense è pensato per proteggere i pagamenti da fenomeni come carding, utilizzo di strumenti rubati e altre attività che possono generare dispute o chargeback.
Il sistema può elaborare informazioni sulla transazione e restituire valutazioni di rischio che l’applicazione può usare per bloccare, accettare o inviare un pagamento a revisione.
Il modello può inoltre essere raffinato annotando gli assessment con eventi successivi del ciclo di pagamento, come accettazione, rifiuto, rimborso o contestazione.
Qui siamo ormai molto lontani dal problema “questo visitatore riesce a selezionare tutti i semafori?”.
Quando queste funzioni hanno senso rispetto a un semplice form anti-spam
Se hai un sito vetrina con un modulo contatti, Account defense e Transaction defense probabilmente aggiungerebbero complessità senza risolvere un problema reale.
Se gestisci invece:
- migliaia di account;
- login ad alto rischio;
- recuperi password;
- autenticazione tramite SMS;
- checkout con volumi significativi;
- pagamenti esposti a carding o chargeback;
la valutazione del rischio può diventare una parte della vera architettura di sicurezza.
La regola è semplice: parti dal rischio da gestire, non dalla feature disponibile.
Policy Engine, Universal key e nuove challenge
La direzione più recente di Fraud Defense rende ancora più evidente il passaggio da CAPTCHA statico a motore di policy.
Alcune di queste funzioni sono però ancora indicate da Google come Preview, quindi non vanno trattate come capacità mature disponibili indistintamente a tutti.
Cosa sono le policy-based challenge
Una policy-based challenge permette di usare il rischio per decidere quando presentare una verifica.
Invece di mostrare una checkbox a tutti, puoi definire una politica del tipo:
score adeguato → continua
score sospetto → presenta challenge
Il vantaggio concettuale è importante: la friction viene applicata soprattutto quando serve.
Policy Engine e Universal key
Con Policy Engine, le regole possono utilizzare condizioni basate su score e altri attributi per decidere quando applicare una challenge. La configurazione corrente utilizza una Universal key e può considerare anche elementi come indirizzi IP, user agent, ASN o identità di bot verificati.
Non è quindi una semplice evoluzione grafica della checkbox.
È una politica di enforcement programmabile attorno al rischio.
Il QR code come nuova modalità di challenge
Fraud Defense documenta anche challenge visuali, audio e tramite QR code.
Nel caso del QR challenge l’utente deve scansionare il codice con un dispositivo mobile per completare la verifica. L’accesso a questa funzione richiede attualmente condizioni specifiche e la documentazione delle challenge policies è marcata Preview.
Per un normale sito WordPress non è una ragione sufficiente per cambiare immediatamente implementazione. È però un segnale utile della direzione in cui sta andando il prodotto.
Perché le funzionalità Preview non vanno confuse con quelle già disponibili per tutti
Quando una feature è in Preview può avere requisiti di accesso, supporto e stabilità diversi da una funzione generalmente disponibile.
Se progetti un sistema critico, non dovresti basare l’intera architettura su una capacità sperimentale soltanto perché è tecnicamente più nuova.
Per la maggior parte dei siti il percorso rimane molto più semplice: identificare l’azione da proteggere, utilizzare il tipo di chiave appropriato, verificare lato server e definire una risposta proporzionata al rischio.
reCAPTCHA v2, v3 o Fraud Defense: quale scegliere
Non esiste una risposta unica perché stiamo confrontando anche generazioni e livelli concettualmente differenti.
La scelta migliore emerge dallo scenario.
Form di contatto e siti a basso rischio
Per un semplice form, l’obiettivo principale è spesso ridurre spam e automazioni senza disturbare gli utenti reali.
Per una nuova integrazione Google Cloud partirei normalmente da una score-based key, soprattutto se il plugin o il sistema utilizzato la supporta correttamente. Google la indica come opzione raccomandata per il web.
Se hai invece una configurazione Classic v2 o v3 già funzionante, la necessità di migrare dipende dal tuo contesto tecnico e dalla roadmap del sito.
Login, registrazione e recupero password
Qui il rischio aumenta.
Uno score basso non dovrebbe necessariamente significare “accesso negato”. Puoi combinarlo con:
- rate limiting;
- verifica email;
- autenticazione multifattore;
- controllo delle password compromesse;
- protezioni contro credential stuffing;
- analisi dell’attività dell’account.
Per WordPress, puoi approfondire anche le altre misure nella guida dedicata alla sicurezza WordPress e nella guida al WordPress login.
Ecommerce e checkout
Un ecommerce deve distinguere almeno due problemi.
Il primo è l’automazione: bot su login, registrazione, form o checkout.
Il secondo è la frode di pagamento.
Per il primo può bastare una normale protezione bot ben configurata. Per il secondo, se il rischio e il volume lo giustificano, Transaction defense aggiunge segnali specifici per carding, strumenti rubati e chargeback.
Se utilizzi WooCommerce, trovi anche una panoramica delle integrazioni nell’articolo sui plugin CAPTCHA per WooCommerce.
API, applicazioni mobile e dispositivi senza JavaScript
Per Android e iOS Google offre integrazioni dedicate.
Per API, IoT o client che non possono utilizzare normalmente JavaScript o gli SDK mobile, reCAPTCHA Express permette invece una verifica server-side. La rinuncia ai segnali client può però ridurre la qualità del rilevamento rispetto alle integrazioni complete.
Tabella decisionale per scenario
| Scenario | Punto di partenza ragionevole | Perché |
|---|---|---|
| Nuovo form web | Score-based | Riduce la friction e restituisce rischio |
| Vecchia integrazione v2 funzionante | Valutare mantenimento/migrazione | Non serve sostituirla solo per moda |
| Vecchia integrazione v3 | Valutare migrazione Cloud | Modello score-based già compatibile concettualmente |
| Login sensibile | Score + controlli account | Il bot score da solo non basta |
| Ecommerce | Score-based + eventuale Transaction defense | Separa bot e frode di pagamento |
| API / IoT | Express | Non richiede normale client integration |
| Protezione edge/WAF | Chiavi e integrazioni WAF | La valutazione può avvenire prima dell’applicazione |
| Policy avanzate | Policy Engine / challenge policies | Controllo più granulare, verificando lo stato Preview |
Quanto costa reCAPTCHA
Il vecchio concetto “reCAPTCHA è sempre gratuito” oggi richiede una precisazione.
Il modello corrente prevede Essentials, Premium ed Enterprise.
Cosa succede alle vecchie chiavi Classic
Le chiavi Classic già esistenti possono ancora essere migrate, ma non è più possibile crearne di nuove. Google indirizza quindi i nuovi progetti verso l’infrastruttura Cloud.
È un dettaglio importante soprattutto quando segui vecchi tutorial che ti chiedono semplicemente di aprire la console Classic e creare una nuova chiave v2 o v3.
La procedura che descrivono potrebbe non corrispondere più al percorso disponibile per un nuovo progetto.
reCAPTCHA Essentials e il limite gratuito
Essentials non richiede billing ed è gratuito fino a 10.000 assessment per mese di calendario per organizzazione.
Il limite viene aggregato tra account e siti dell’organizzazione. Una volta superato, le nuove richieste Essentials restituiscono un errore di quota fino al reset del periodo.
Quindi “10.000 gratis” non significa necessariamente 10.000 per ogni singolo sito.
reCAPTCHA Premium: quando iniziano gli addebiti
Con billing attivo il progetto passa al modello Premium.
La struttura corrente prevede:
- primi 10.000 assessment senza costo;
- da 10.001 a 100.000 assessment: 8 dollari complessivi;
- oltre 100.000 assessment: 0,001 dollari per assessment, equivalenti a 1 dollaro ogni 1.000.
Il billing permette inoltre di accedere a funzioni non disponibili in Essentials.
I prezzi dei servizi cloud possono cambiare: prima di progettare un budget basati sempre sulla documentazione ufficiale di billing di Fraud Defense.
Enterprise: quando serve un contratto dedicato
Enterprise è orientato ai clienti con esigenze maggiori e utilizza un modello di subscription con impegno minimo.
La tabella ufficiale dei tier Fraud Defense indica un commitment minimo di 12 mesi e un volume mensile concordato, oltre a funzioni più avanzate per analisi, account management e investigazione.
Per un normale sito WordPress questa complessità è generalmente sproporzionata. Per piattaforme ad alto volume o con team dedicati alla fraud analysis può invece essere coerente con il problema da risolvere.
Perché assessment, visitatori e pageview non sono la stessa cosa
Un assessment è una valutazione eseguita dal servizio.
Non coincide automaticamente con:
- un visitatore;
- una sessione;
- una pagina visualizzata;
- un ordine.
Se proteggi più azioni dello stesso percorso, uno stesso utente può generare più assessment.
Quando valuti i costi devi quindi partire dal numero di verifiche realmente eseguite, non dal traffico web complessivo.
Questa è una sezione in cui le semplificazioni possono essere particolarmente pericolose.
Google dichiara reCAPTCHA compatibile con i propri impegni GDPR per Google Cloud, ma questo non significa automaticamente che qualsiasi implementazione sul tuo sito sia conforme senza ulteriori valutazioni.
Quali dati servono alla valutazione del rischio
La finalità dichiarata del trattamento è legata alla sicurezza, alla prevenzione di frodi e comportamenti illeciti.
La quantità e il tipo di segnali dipendono dalla funzione utilizzata. Una normale valutazione bot non è equivalente, per esempio, a Transaction defense, dove vengono forniti anche dati pertinenti alla transazione.
Per questo la privacy policy del sito dovrebbe descrivere l’effettiva implementazione, non copiare una formula generica da un altro progetto.
Il cookie _GRECAPTCHA
Google conferma che reCAPTCHA imposta il cookie necessario _GRECAPTCHA per fornire l’analisi del rischio.
La presenza del cookie è quindi un elemento da considerare nella configurazione della privacy e degli eventuali strumenti di gestione del consenso.
Non basta però il nome del cookie, da solo, per determinare automaticamente quale sia la corretta base giuridica della tua specifica implementazione.
Cosa è cambiato nel rapporto data controller/data processor
Google ha modificato la propria posizione contrattuale e opera ora come responsabile del trattamento per i Customer Data reCAPTCHA, mentre il cliente rimane titolare.
In conseguenza di questo cambiamento sono stati rimossi dal badge reCAPTCHA i riferimenti obbligatori alle Privacy Policy e ai Termini di Google; Google invita inoltre i clienti a verificare che la propria informativa descriva adeguatamente la finalità del trattamento svolto tramite il servizio.
È una modifica concreta, soprattutto se il tuo sito utilizza testi o informative derivati dalle vecchie modalità reCAPTCHA.
Informativa privacy, base giuridica e consenso: cosa verificare sul proprio sito
Per un sito italiano o europeo controllerei almeno:
- quale versione o integrazione reCAPTCHA è effettivamente caricata;
- su quali pagine viene eseguita;
- quali cookie e richieste di rete produce;
- quale finalità stai perseguendo;
- cosa dichiara la tua privacy policy;
- come si integra con il tuo sistema di gestione del consenso;
- se plugin, CMP e impostazioni tecniche si comportano davvero come documentato.
Non esiste una frase universale del tipo “reCAPTCHA richiede sempre consenso” o “reCAPTCHA non richiede mai consenso” che possa sostituire l’analisi della configurazione concreta e della base giuridica applicabile.
Per casi complessi o ad alto impatto è opportuno coinvolgere anche chi segue gli aspetti privacy e legali del progetto.
Come usare reCAPTCHA su WordPress e WooCommerce
Su WordPress raramente implementerai reCAPTCHA partendo direttamente dalle API Google.
Più spesso la funzione arriva tramite un plugin per form, sicurezza, login o WooCommerce.
Questo semplifica l’installazione, ma crea un nuovo problema: la tua configurazione è limitata da ciò che il plugin ha effettivamente implementato.
Dove viene normalmente integrato: form, login, registrazione e checkout
I punti più comuni sono:
- form di contatto;
- login WordPress;
- recupero password;
- registrazione utenti;
- commenti;
- form WooCommerce;
- checkout;
- altri moduli esposti pubblicamente.
Non significa che devi abilitarlo ovunque.
Più verifiche introduci, più devi considerare esperienza utente, traffico, assessment e rischio di conflitti con cache, ottimizzazioni JavaScript o altri sistemi di sicurezza.
Per confrontare le estensioni disponibili puoi partire dalla nostra selezione di plugin CAPTCHA per WordPress.
Site key, secret key e integrazioni legacy
Se un plugin ti chiede site key + secret key e parla specificamente di v2 o v3, molto probabilmente sta utilizzando il modello Classic o un meccanismo di compatibilità con le chiavi storiche.
Google mantiene infatti modalità per recuperare secret key legacy e migrare le vecchie chiavi.
Non considerarlo automaticamente un problema.
Devi però sapere quale stack stai usando, soprattutto quando segui documentazione recente che parla invece di project, assessment, API Google Cloud e differenti tipi di key.
Cosa controllare quando un plugin supporta soltanto v2 o v3
Prima di installare un plugin controlla:
- quali modalità supporta realmente;
- quando è stato aggiornato;
- se verifica il token server-side;
- quali form può proteggere;
- se supporta WooCommerce quando ti serve;
- se gestisce correttamente errori e indisponibilità del servizio;
- se la sua documentazione riflette ancora la configurazione Google corrente.
Il semplice logo “reCAPTCHA” nella pagina del plugin non basta.
Un’estensione può supportare perfettamente una vecchia chiave v2 ma non una nuova integrazione Cloud.
Perché reCAPTCHA non sostituisce 2FA, rate limiting, WAF e una strategia di sicurezza
Un CAPTCHA può filtrare una parte delle richieste automatizzate. Non corregge una password debole, una vulnerabilità di un plugin, un account amministratore compromesso o una configurazione server sbagliata.
Su un login WordPress serio combinerei quindi, secondo il livello di rischio:
password robuste + aggiornamenti + rate limiting + MFA + protezione bot + monitoraggio + eventuale WAF.
È lo stesso principio che utilizziamo nella guida completa alla sicurezza WordPress: nessuna singola misura dovrebbe diventare l’unico confine di sicurezza.
Se devi intervenire su un sito esistente e la configurazione di plugin, login o protezioni anti-spam è diventata difficile da gestire, puoi valutare anche un intervento di assistenza WordPress.
reCAPTCHA o Cloudflare Turnstile?
Il confronto è utile, ma va impostato correttamente.
Cloudflare Turnstile e l’intero Google Cloud Fraud Defense non sono prodotti perfettamente equivalenti.
Turnstile è principalmente una soluzione di verifica anti-bot. Fraud Defense può invece estendersi alla protezione di account e transazioni. Se restringiamo il confronto alla bot defense, però, le alternative diventano molto più confrontabili.
La differenza fra un prodotto anti-bot e una piattaforma antifrode più ampia
Se vuoi soltanto proteggere un form WordPress da spam e bot, la domanda può essere:
Turnstile o reCAPTCHA?
Se vuoi identificare account takeover, password compromesse, frodi SMS o transazioni rischiose, la domanda cambia:
quale architettura di fraud prevention serve alla mia applicazione?
In quel secondo scenario Turnstile non sostituisce da solo tutte le funzioni offerte dai tier avanzati di Fraud Defense.
UX, privacy, controllo e complessità di implementazione
Turnstile è interessante soprattutto se vuoi una verifica anti-bot con un’esperienza meno legata alle classiche challenge visuali.
reCAPTCHA offre invece molte più possibilità quando il progetto necessita di score, account protection, transaction protection, policy e integrazione nell’ecosistema Google Cloud.
La differenza non è quindi semplicemente:
gratis contro pagamento
oppure:
checkbox contro widget invisibile.
Devi confrontare almeno funzione, esperienza utente, privacy, integrazione server-side, costi potenziali e rischio realmente presente.
Abbiamo analizzato questi aspetti separatamente nella guida a Cloudflare Turnstile e al suo utilizzo su WordPress.
Quando ha senso mantenere reCAPTCHA e quando valutare Turnstile
Mantieni o scegli reCAPTCHA quando la tua integrazione funziona bene, hai bisogno del risk scoring Google, utilizzi già l’ecosistema Cloud oppure prevedi funzioni avanzate di bot, account o transaction protection.
Valuta Turnstile quando il problema principale è fermare bot e spam con un sistema più focalizzato sulla verifica anti-bot e vuoi ridurre la dipendenza dalle esperienze CAPTCHA tradizionali.
Se possiedi già una configurazione funzionante, non cambierei tecnologia soltanto perché esiste un’alternativa più recente. Prima misurerei:
- spam che passa;
- utenti legittimi bloccati;
- friction;
- errori;
- costi;
- manutenzione;
- compatibilità con il resto dello stack.
Una migrazione ha senso quando risolve un problema reale.
Conclusione
reCAPTCHA non è più soltanto la casella “Non sono un robot”, e nemmeno la scelta può essere ridotta a v2 contro v3.
Quelle versioni restano importanti perché esistono ancora in un numero enorme di siti e plugin, ma per una nuova implementazione il modello da comprendere è quello di Google Cloud: chiavi score-based, checkbox e policy-based per la bot defense, integrate in una piattaforma Fraud Defense che può estendersi a account e transazioni.
Per un normale sito WordPress partirei dalla soluzione meno invasiva che risolve davvero il problema: protezione score-based o una buona integrazione anti-bot, verifica server-side e misure di sicurezza complementari. Non complicherei il progetto con funzioni enterprise se devi semplicemente fermare lo spam di un form.
Se invece gestisci login ad alto rischio, migliaia di account o pagamenti esposti a frodi, il vero salto non è da v2 a v3: è passare dalla semplice verifica anti-bot alla gestione strutturata del rischio.
È questa la distinzione che dovrebbe guidare la scelta.