Antispam per formulari: CAPTCHA e blocco dei bot - Modulo PrestaShop

Lo spam non si ferma al widget del formulario

Un CAPTCHA classico protegge la visualizzazione del formulario, non la sua elaborazione. Un bot che invia direttamente una richiesta POST al controller di contatto, registrazione o newsletter salta il widget e lascia il suo messaggio. È per questo che alcune boutique ricevono ancora spam con reCAPTCHA attivo. I moduli gratuiti spesso coprono un solo fornitore e pochi formulari, senza limiti di invio, senza registro e senza modo di verificare cosa accade.

Antispam per formulari: CAPTCHA e blocco dei bot mette un controllo lato server davanti a ogni formulario protetto. L’invio viene esaminato all’inizio della richiesta, prima che PrestaShop o il modulo del formulario lo elabori: un invio rifiutato non crea account, non invia messaggi, non iscrive alla newsletter e non pubblica recensioni. Il modulo funziona senza account di terzi né chiave per impostazione predefinita; un CAPTCHA esterno resta una scelta, formulario per formulario.

Una protezione all’invio, prima dell’elaborazione

Ogni formulario protetto riceve un token firmato, un campo trappola invisibile e un tempo minimo di compilazione. Il server controlla la firma del token, l’età della pagina, il campo trappola e i duplicati prima di accettare l’invio. Un bot che invia senza caricare la pagina non ha un token valido; un bot che compila tutto il formulario compila anche il campo trappola.

• Token firmato: legato al formulario, alla boutique e all’ora; scade dopo 12 ore per impostazione predefinita e si rinnova al primo contatto con un formulario vecchio.
• Campo trappola: nascosto fuori schermo, mai raggiungibile da tastiera, con un nome scelto a caso all’installazione.
• Tempo minimo: da 0 a 30 secondi secondo il formulario, da 1 a 3 secondi per impostazione predefinita sui formulari sensibili, per fermare gli invii istantanei.
• Duplicati: un contenuto identico inviato di nuovo nella finestra configurata viene rifiutato, mentre una correzione dopo il rifiuto passa.

Una rete di sicurezza protegge i visitatori reali: finché un formulario non ha mai inviato i campi del modulo (un tema o un modulo che disegna il formulario a modo suo), l’assenza del token viene registrata senza bloccare e la dashboard propone di testare la protezione. Quando un invio valido è stato visto, l’assenza del token viene rifiutata.

I metodi senza account di terzi sono attivi per impostazione predefinita

All’installazione i sette formulari nativi passano in modalità protetta, senza CAPTCHA esterno: contatto, creazione account, accesso, formulario cliente dell’ordine, password dimenticata, newsletter e recensioni prodotti. La boutique è protetta senza chiave, senza abbonamento e senza chiamate a un servizio esterno. Nessuno script del fornitore viene caricato finché non ne scegli uno.

Il CAPTCHA che scegli, formulario per formulario

Quando vuoi una verifica in più, scegli un fornitore per un formulario: Google reCAPTCHA v2 (casella o invisibile), reCAPTCHA v3 con soglia di punteggio, Cloudflare Turnstile, hCaptcha (normale, compatto o invisibile) o Friendly Captcha. Inserisci le tue chiavi, il modulo non le mostra mai in chiaro e un pulsante di test verifica che siano accettate. Per impostazione predefinita lo script del fornitore viene caricato solo nelle pagine che contengono un formulario protetto da quel fornitore, al primo contatto con il formulario.

• Se il fornitore non risponde: lasciar passare (l’invio passa ed è registrato come senza controllo) o rifiutare, secondo la tua scelta.
• Consenso: lo script può attendere l’accordo del visitatore, con il modulo Cookies GDPR o un altro strumento di consenso; senza accordo il formulario resta protetto dai controlli nativi, oppure mostra un messaggio se scegli di chiedere il consenso.
• Accessibilità: le varianti invisibili evitano una casella in più; un CAPTCHA visibile può ostacolare alcuni visitatori, la scelta è tua.

Limiti di invio, liste e blocchi temporanei

Ogni invio conta in una finestra scorrevole per indirizzo IP e per indirizzo e-mail, con soglie impostabili per formulario. Oltre la soglia l’invio viene rifiutato; dopo diversi avvisi l’indirizzo viene bloccato temporaneamente su tutti i formulari protetti. La navigazione resta sempre possibile: il modulo non blocca mai una pagina.

• Liste di blocco e di consentiti: indirizzi IPv4 e IPv6, intervalli CIDR, indirizzi e-mail, domini e schemi con carattere jolly; inserimento manuale, importazione ed esportazione CSV.
• Domini usa e getta: una lista fornita all’installazione che puoi ampliare o ridurre, e un controllo MX opzionale con cache.
• Un indirizzo presente in entrambe le liste è consentito: vince la lista dei consentiti.

Osservare prima di bloccare, capire dopo

La modalità osservazione esegue tutti i controlli e registra ciò che sarebbe stato bloccato, senza rifiutare nulla. Per qualche giorno verifichi che i clienti passino, poi attivi la protezione formulario per formulario. La dashboard mostra invii consentiti, bloccati, osservati, senza controllo ed esenti, il tasso di blocco, un grafico a 30 giorni, il dettaglio per formulario e per motivo e gli indirizzi più bloccati.

Il registro dei tentativi bloccati indica, per ogni rifiuto, il formulario, il motivo, la data, l’indirizzo mascherato o con hash e il dominio e-mail. Puoi bloccare un indirizzo o un intervallo, consentire un indirizzo, bloccare un dominio o revocare un blocco con un clic, poi esportare il registro in CSV. La pulizia è automatica dopo 30 giorni per impostazione predefinita.

Lo strumento Testa la mia protezione legge la pagina del formulario come un visitatore, controlla che i campi, il token e lo script siano presenti, invia un invio diretto senza campi per verificare che venga rifiutato e controlla le chiavi del fornitore scelto. Il risultato resta visibile fino al test successivo.

I formulari coperti

Il modulo protegge i sette formulari nativi di PrestaShop, compresa la creazione dell’account durante l’ordine. Per i formulari di altri moduli ci sono due soluzioni: una regola per controller, con il campo che marca l’invio e il formato di risposta atteso, oppure l’API PHP documentata perché un modulo chiami i controlli dal proprio codice. Una regola pronta copre gli avvisi di disponibilità di ps_emailalerts.

L’ordine in sé non viene mai filtrato: né il carrello, né il pagamento, né la conferma, né gli indirizzi. Le soglie del formulario cliente dell’ordine sono volutamente ampie e senza tempo minimo, per non perdere mai una vendita.

Verifica e-mail alla registrazione, opzionale

Disattivata per impostazione predefinita, aggiunge un link firmato e con scadenza alla registrazione nella pagina di creazione account. Un account in attesa non può accedere prima della conferma e può chiedere un nuovo link. La boutique non trattiene mai un account se non invia e-mail o se l’invio fallisce, e un account in attesa resta liberamente accessibile se il modulo viene disattivato o la licenza scade.

Esenzioni e privacy

I dipendenti connessi al back office, i crawler dei motori di ricerca verificati, i gruppi di clienti che esenti, gli indirizzi consentiti, i clienti connessi (secondo il formulario) e le attività pianificate non vengono controllati. Per impostazione predefinita il registro non contiene mai un indirizzo in chiaro: l’indirizzo è mascherato, un’impronta con hash serve alle liste e ai limiti, e il dominio e-mail è conservato senza l’indirizzo completo. Scegli il periodo di conservazione e puoi esportare o cancellare i dati tramite gli hook GDPR.

Il modulo aiuta a ridurre lo spam e a limitare i dati raccolti; non certifica la conformità al GDPR e non sostituisce un parere legale. I CAPTCHA esterni hanno condizioni e informativa privacy proprie: spetta a te citarli nella tua informativa e scegliere il consenso adeguato.

Multiboutique, lingue e licenza

Impostazioni, formulari, registro e statistiche sono propri di ogni boutique; le voci delle liste possono appartenere a una boutique o essere condivise. L’interfaccia e i messaggi esistono in francese, inglese, spagnolo, italiano e polacco; i temi Classic e Hummingbird funzionano senza modifiche. La disinstallazione conserva i dati per impostazione predefinita, con un’opzione per eliminarli.

Il modulo funziona con una licenza WePresta valida. Senza licenza valida si disattiva: i formulari non vengono più controllati, non viene mostrato alcun CAPTCHA e nulla viene registrato, quindi lo spam può tornare. Le impostazioni, le liste e il registro sono conservati e il modulo si riattiva appena la licenza è valida.

Requisiti e limiti

• PrestaShop 1.7.8, 8.0+ o 9.0+; PHP 7.4 o successivo.
• Nessun account a pagamento obbligatorio. I fornitori di CAPTCHA sono facoltativi e richiedono le proprie chiavi; Cloudflare Turnstile richiede un account Cloudflare.
• Un’attività pianificata (indirizzo con token o riga di comando) esegue la manutenzione giornaliera: pulizia del registro, dei contatori e dei blocchi scaduti.
• Le verifiche CAPTCHA e il controllo MX usano chiamate di rete in uscita; senza rete si applica il comportamento scelto.
• Nessun modulo può promettere zero spam. Questo modulo riduce fortemente gli invii automatizzati e offre gli strumenti per vedere e regolare; non sostituisce l’informativa privacy né un parere legale.
• Un limite troppo severo può ostacolare visitatori dietro lo stesso indirizzo (azienda, operatore mobile): usa la modalità osservazione e le liste dei consentiti prima di attivare.