Il CAPTCHA c’è – ma non protegge nulla

Molti titolari di siti web aggiungono un CAPTCHA al proprio modulo di contatto, vedono comparire il piccolo badge o la casella di controllo e considerano risolto il problema dello spam. Poi la spazzatura continua ad arrivare. Spesso il CAPTCHA in sé funziona – semplicemente non è collegato a nulla che possa fermare un bot. Questo articolo illustra i modi tipici in cui reCAPTCHA, hCaptcha e Cloudflare Turnstile finiscono per essere solo decorazione, e come verificare i propri moduli.

Dove avviene davvero la protezione

Tutti e tre i servizi funzionano secondo lo stesso principio. Uno script nel browser esegue i suoi controlli e consegna al modulo un token – una breve stringa che dice “questo visitatore ha superato il controllo”. Il token viaggia con l’invio del modulo fino al Suo server. Solo lì avviene la vera decisione: il Suo server invia il token insieme a una chiave segreta al provider e riceve una risposta – successo o fallimento e, per reCAPTCHA v3, anche un punteggio. Se manca un qualsiasi anello di questa catena, il widget sembra comunque del tutto normale, ma un bot che invia direttamente al gestore del Suo modulo passa senza ostacoli.

La chiave di test che lascia passare tutto

Google, hCaptcha e Cloudflare pubblicano speciali chiavi di test affinché gli sviluppatori possano eseguire test automatizzati senza risolvere rompicapi. Con il segreto di test corrispondente, la verifica riesce sempre – è proprio questo il loro scopo. Sono pensate per ambienti locali e di staging, ma sopravvivono regolarmente al passaggio in produzione: uno sviluppatore le inserisce durante la realizzazione, il sito va online e nessuno le sostituisce. reCAPTCHA mostra almeno un avviso nel widget che indica che serve solo per i test, ma con una configurazione invisibile quasi nessuno ci fa caso. Se la chiave del sito di test e il segreto di test sono entrambi attivi, ogni invio passa, che provenga da una persona o da un bot; se solo la chiave del sito è di test, la verifica invece fallisce e i messaggi reali possono essere respinti.

Un token che nessuno controlla

Il secondo classico è un server che non interpella mai il provider. Il widget funziona, un token viene creato e inviato, e poi il gestore del modulo semplicemente lo ignora. Le fonti tipiche sono moduli scritti a mano, frammenti di codice copiati che coprono solo il lato browser e impostazioni del plugin lasciate a metà. Un caso affine: il server chiama sì il servizio di verifica, ma controlla solo che la richiesta sia andata a buon fine, non che cosa dica la risposta. Oppure la soglia del punteggio per reCAPTCHA v3 è impostata a 0, il che accetta qualsiasi punteggio il servizio possa restituire. Alcuni gestori, inoltre, “falliscono in modo permissivo”: se il token manca o la verifica fallisce, accettano comunque il messaggio – e a un bot basta omettere il token.

Quando il widget non si carica mai davvero

Altre configurazioni errate guastano invece il lato browser. Se la chiave del sito non è registrata per il dominio – tipico dopo un passaggio da staging a produzione, un cambio di dominio o un nuovo sottodominio – il provider rifiuta di emettere token e mostra un errore nel widget o nella console del browser. Dopo un cambio di tema o un aggiornamento di un plugin, il markup del widget può essere ancora presente nella pagina mentre lo script che lo rende funzionante è sparito. Uno strumento di consenso ai cookie può avere lo stesso effetto se blocca lo script del CAPTCHA finché il visitatore non accetta. Che cosa succede dopo dipende dal server: se esige un token valido, i visitatori reali non possono più inviare messaggi e nessuno si accorge delle richieste perse; se non lo esige, i bot passano liberamente.

Altri due casi sfuggono facilmente. Con reCAPTCHA v3, il badge nell’angolo mostra solo che lo script è caricato da qualche parte nella pagina – magari dal tema o da un altro plugin – mentre l’integrazione nel plugin per moduli stesso è disattivata. E i plugin di caching possono memorizzare una pagina insieme a un token incorporato nell’HTML. I token CAPTCHA sono validi solo per pochi minuti e possono essere verificati una sola volta, quindi un token in cache fallisce per i visitatori reali; la tentazione di “risolvere” disattivando il controllo rimuove silenziosamente la protezione.

Un breve autocontrollo

1. 1Apra la pagina del modulo in una finestra privata, apra gli strumenti per sviluppatori del browser e cerchi nella console errori provenienti dallo script del CAPTCHA.
2. 2Verifichi che il widget compaia effettivamente – una volta prima e una volta dopo aver accettato il banner dei cookie – e che il modulo non possa essere inviato mentre manca.
3. 3Nella console di amministrazione del provider, verifichi che la chiave del sito elenchi il Suo dominio di produzione (incluse varianti come www) e che le chiavi nel Suo plugin per moduli o nel Suo codice corrispondano – e non siano chiavi tratte dalla documentazione o da un ambiente di staging.
4. 4Nelle impostazioni del plugin per moduli, si assicuri che l’integrazione del CAPTCHA sia attivata per questo specifico modulo; per reCAPTCHA v3, verifichi che la soglia del punteggio sia superiore a 0.
5. 5Se ha accesso al codice, individui la verifica lato server e controlli che respinga l’invio quando la risposta è negativa o il token manca.
6. 6Escluda la pagina del modulo dalla cache a pagina intera, oppure si assicuri che il token venga creato ex novo nel browser.
7. 7Invii un vero messaggio di prova e verifichi che arrivi; ripeta il controllo dopo modifiche al tema, ai plugin o allo strumento di consenso.

Un CAPTCHA è un livello, non l’intera protezione. Combinato con un campo honeypot, un controllo dei tempi e un filtro lato server, una configurazione errata in un punto non lascia il modulo spalancato. Se desidera un quadro rapido della situazione dei Suoi moduli, inserisca il Suo dominio su formexposed.com – il report mostra se le parti della Sua configurazione CAPTCHA visibili dall’esterno sono in ordine.