Che cosa protegge davvero un modulo: CAPTCHA, honeypot, trappola temporale, CSRF

Lo spam tramite i moduli di contatto raramente proviene da una persona che digita a mano. Per lo più si tratta di software che trova i moduli, compila ogni campo e invia il risultato – migliaia di volte. Esistono diverse difese, e agiscono in punti molto diversi. Sapere che cosa fa davvero ciascuna aiuta a evitare due errori: un modulo senza una vera protezione e un modulo protetto in modo così pesante che le persone reali rinunciano.

Honeypot e trappola temporale: filtri invisibili

Un honeypot è un campo aggiuntivo che le persone non vedono mai, ad esempio un campo chiamato “website” nascosto con CSS. I bot semplici compilano ogni campo, quindi un honeypot compilato segnala automazione e il server può scartare silenziosamente il messaggio. I bot scritti appositamente per il Suo sito, o quelli che renderizzano la pagina come un browser, lo saltano. Lo nasconda correttamente: un campo semplicemente spostato fuori dallo schermo può essere annunciato dagli screen reader, raggiunto con il tasto Tab o compilato dalla compilazione automatica. Usi aria-hidden, tabindex -1 e autocomplete off, oltre a un’etichetta neutra che chieda a chiunque vi arrivi di lasciarlo vuoto.

Una trappola temporale registra quando il modulo è stato consegnato e respinge gli invii che arrivano in tempi non plausibili. Le persone hanno bisogno di qualche secondo per leggere e digitare; molti script inviano in una frazione di secondo. Il timestamp deve essere controllato sul server e protetto da manomissioni, ad esempio firmato o conservato nella sessione – un semplice campo nascosto con l’ora viene banalmente riscritto dal bot. Mantenga bassa la soglia, perché la compilazione automatica rende veloci anche le persone reali. I bot che semplicemente aspettano passano: una trappola temporale è un filtro, non un muro.

CAPTCHA: efficace, ma non gratuito

Un CAPTCHA chiede la prova che non sia all’opera un bot – dai rompicapi con immagini ai controlli che si svolgono in background; tra i servizi più comuni figurano reCAPTCHA, hCaptcha, Cloudflare Turnstile e Friendly Captcha. Ferma la maggior parte dell’automazione generica, ed è per questo che è così diffuso. Ma ogni rompicapo visibile è un ostacolo davanti al quale alcuni visitatori rinunciano, e la maggior parte dei servizi carica uno script di terze parti, il che solleva questioni di privacy e di consenso. Un CAPTCHA, inoltre, aiuta solo se è configurato correttamente: una chiave del sito di test pubblica, un widget senza il suo script o un token che il server non verifica mai sembrano protezione, ma non lo sono. Una verifica gratuita su formexposed.com segnala tali errori dall’esterno.

L’accessibilità fa parte di questo costo. I rompicapi con immagini escludono le persone cieche e molte persone ipovedenti, le alternative audio non aiutano le persone sordocieche e i compiti logici complicati pesano sulle persone con disabilità cognitive. Il criterio di successo 1.1.1 delle WCAG 2.2 richiede un’alternativa testuale che descriva lo scopo del CAPTCHA e forme alternative per sensi diversi. I controlli in background evitano gran parte di questi problemi, ma quando diventano sospettosi il ripiego è spesso di nuovo un rompicapo visivo – testi questo percorso con la tastiera e con uno screen reader.

Token CSRF: protezione dalla falsificazione, non dallo spam

Un token CSRF è un valore casuale che il server inserisce nel modulo e si aspetta di ricevere indietro. È stato concepito contro la cross-site request forgery, in cui un altro sito web induce il browser di un visitatore a inviare una richiesta che il visitatore non ha mai voluto. Su un modulo di contatto pubblico ha un effetto collaterale: i bot che inviano direttamente all’indirizzo del modulo senza caricare la pagina vengono respinti. Qualsiasi bot che scarica la pagina e rimanda il token passa. La maggior parte dei framework e dei plugin per moduli include comunque token CSRF – li mantenga attivi, ma non li consideri una protezione antispam.

Che cosa deve avvenire sul server

• Validi di nuovo ogni campo sul server: campi obbligatori, lunghezza, formato e-mail e nessuna interruzione di riga nei campi che finiscono negli header della posta.
• Verifichi i token CAPTCHA e proof-of-work a ogni invio, presso il servizio emittente o nel proprio codice, e respinga i token riutilizzati.
• Limiti gli invii per indirizzo IP e intervallo di tempo. Ciò ferma le ondate da un’unica fonte; lo spam distribuito su molti indirizzi richiede altri livelli.
• Valuti il proof-of-work: prima dell’invio, il browser risolve un piccolo compito di calcolo. I visitatori non vedono alcun rompicapo e nulla viene tracciato, ma l’invio di massa diventa costoso.

Una combinazione sensata: due o tre livelli

1. 1Inizi con i livelli invisibili: un honeypot accessibile e una trappola temporale firmata, entrambi controllati sul server.
2. 2Aggiunga una limitazione della frequenza per indirizzo IP, così che un’unica fonte non possa inondare il modulo.
3. 3Se lo spam mirato continua a passare, aggiunga il proof-of-work o un CAPTCHA – preferibilmente uno senza rompicapo visibile e con un’alternativa accessibile.
4. 4Mantenga il token CSRF fornito dal Suo framework – come extra, non come difesa.
5. 5Testi il risultato come un visitatore – solo con la tastiera, con uno screen reader, su uno smartphone – e verifichi che i messaggi reali arrivino ancora.

Su molti siti, honeypot, trappola temporale e limitazione della frequenza insieme eliminano già la maggior parte dello spam generico senza alcun ostacolo visibile; un CAPTCHA è la riserva per quando ciò non basta. Su WordPress, il plugin gratuito formexposed combina honeypot, controllo dei tempi e proof-of-work senza bisogno di Google. Per vedere che cosa mostra il Suo modulo dall’esterno – quali livelli sono presenti, se un CAPTCHA è configurato in modo efficace – una verifica gratuita su formexposed.com richiede solo un dominio, nessun account. Non può vedere il codice del Suo server, quindi la parte lato server resta compito Suo.