reCAPTCHA per PrestaShop: proteggere il tuo negozio da spam e bot

Ultimo aggiornamento: giugno 2026.

Un negozio PrestaShop senza CAPTCHA non corre un rischio ipotetico: è un bersaglio che il traffico automatizzato trova da solo. I bot scandagliano il web alla ricerca degli endpoint standard dei form PrestaShop e, una volta trovato il tuo, iniziano a martellarli: registrazioni false su AuthController, spazzatura nel form di contatto, tentativi di combinazioni di password contro l'accesso, raffiche di email di reimpostazione. Non serve che qualcuno sappia che il tuo negozio esiste. I form sono inclusi in PrestaShop, i bot li conoscono e l'installazione standard di PrestaShop ha zero protezione dai bot su tutti questi punti.

Questa guida serve a chiudere quel varco: cosa fanno davvero i bot a un negozio PrestaShop, quali form specifici attaccano e in che modo CAPTCHA blocca ciascun abuso. Se la tua preoccupazione è il rovescio della medaglia, cioè aggiungere protezione senza allontanare i clienti reali con verifiche fastidiose, questa è una questione di conversione che trattiamo separatamente in reCAPTCHA senza infastidire i clienti reali. Qui l'attenzione è sulla minaccia e sulla difesa.

Cosa fanno davvero i bot a un negozio PrestaShop

"Spam e bot" resta un'espressione vaga finché non la vedi colpire il tuo pannello di amministrazione. Ecco come si presenta in una vera installazione PrestaShop, collegata alla parte del negozio che danneggia.

Il filo conduttore è questo: il danno raramente è una violazione spettacolare. È un degrado lento: un database clienti di cui non puoi più fidarti, una casella di assistenza che temi di aprire, una reputazione email che scende in silenzio. CAPTCHA sui form giusti taglia fuori la maggior parte di questi abusi all'ingresso. (Per il lato più serio dello spettro, come credential stuffing, abusi su ordini/carte e skimmer, CAPTCHA è uno strato tra diversi; vedi la checklist completa per rafforzare la sicurezza e l'anatomia di un attacco in stile Magecart.)

Quali form PrestaShop proteggere e quali lasciare stare

L'istinto di "mettere CAPTCHA ovunque" è sbagliato. I bot si concentrano su pochi endpoint e ogni form che proteggi aggiunge un po' di attrito. Proteggi in base a dove arrivano gli attacchi, non a sensazione.

Proteggi prima questi: è qui che si trovano i bot

• Form di registrazione. Il bersaglio numero uno dei bot in qualsiasi negozio PrestaShop. Se non è protetto, è così che cresce la pila di account falsi. Non è negoziabile.
• Form di contatto. Il secondo più colpito. È ciò che ti separa da una casella del Servizio clienti piena di rumore.
• Form di accesso. Impedisce ai tentativi a forza bruta di diventare sia un problema di carico server sia un problema di account compromessi.

Proteggi poi questi

• Reimpostazione password. Chiude il vettore del flood di email di reimpostazione che danneggia la reputazione del mittente.
• Iscrizione alla newsletter. Tiene le iscrizioni false fuori dalla lista.
• Recensioni prodotto (se usi un modulo recensioni). I bot pubblicano recensioni false per manipolare le valutazioni.

Lasciali stare, salvo problemi dimostrati

• Pagamento. Aggiungere un CAPTCHA visibile nella fase di pagamento è un danno autoinflitto: aumenta gli abbandoni sulla pagina più preziosa del negozio. Intervieni solo se vedi frodi reali in fase di pagamento e sempre soltanto con punteggio invisibile (mai una casella da spuntare). Questi compromessi sono esattamente il problema del "non infastidire i clienti reali" trattato nella guida collegata.
• Casella di ricerca e aggiunta al carrello. Raramente sono un vero bersaglio; l'attrito non ne vale la pena.

reCAPTCHA v2 vs v3 vs hCaptcha: quale protezione usare

La versione che scegli cambia sia quanto è difficile per un bot passare, sia quanto un cliente reale se ne accorge. Per un negozio PrestaShop ci sono tre opzioni realistiche:

Per la maggior parte dei negozi PrestaShop la scelta è tra v3 per il punteggio invisibile e v2 o hCaptcha per una sfida esplicita. Il modulo attuale mprrecaptcha ti permette di scegliere reCAPTCHA v2, reCAPTCHA v3 o hCaptcha e di impostare la soglia di punteggio v3; non passa automaticamente da v3 a v2 sui punteggi al limite, quindi la gestione dei punteggi bassi è una decisione di regolazione e rifiuto, non una seconda sfida. Quale soglia esatta impostare e come evitare di bloccare persone reali è la parte di regolazione del lavoro, trattata nella guida collegata.

Portare CAPTCHA sui form di PrestaShop: la meccanica

PrestaShop non include alcun CAPTCHA, quindi la protezione passa da un modulo. Ciò che conta è come si aggancia, perché questo determina se blocca davvero un invio o si limita a decorare il form.

Passaggio 1: genera le chiavi

Per reCAPTCHA registra il sito su www.google.com/recaptcha/admin; per hCaptcha, nel pannello hCaptcha. In entrambi i casi ottieni una Site Key pubblica (renderizzata nella pagina) e una Secret Key privata (usata lato server per la verifica). Aggiungi sia il dominio www sia quello non-www. Le chiavi sono vincolate al dominio: un dominio non corrispondente può rompere la validazione CAPTCHA o bloccare invii legittimi, quindi registra una coppia separata per ogni ambiente e verifica che il form fallisca in modo chiuso (rifiuti invece di lasciare passare silenziosamente gli invii) quando il token non viene verificato.

Passaggio 2: come si aggancia un modulo fatto bene

Le impostazioni importanti sono fornitore, chiavi, form protetti e soglia v3.

In un modulo reale, gli hook di visualizzazione renderizzano il widget e gli hook di azione rifiutano l'invio prima che PrestaShop crei l'account, il messaggio o l'iscrizione. Questi sono gli hook rilevanti dal sorgente di mprrecaptcha.

public function getHooks()
{
    return [
        'displayHeader',
        'displayFooter',
        'displayCustomerLoginFormAfter',
        'displayCustomerAccountForm',
        'displayNewsletterRegistration',
        'displayGDPRConsent',
        'actionContactFormSubmitBefore',
        'actionSubmitAccountBefore',
        'actionCustomerLoginBefore',
        'actionNewsletterRegistrationBefore',
    ];
}

Questa è la parte che separa la protezione reale dal teatro. Un bot non compila il form a mano: invia un POST direttamente al controller. Quindi la verifica deve avvenire lato server, prima che PrestaShop elabori l'invio, non solo come widget disegnato sulla pagina. Il requisito chiave è lo stesso in ogni versione: il token viene validato lato server prima che vengano elaborati account, messaggio di contatto, accesso o iscrizione alla newsletter. I nomi esatti degli hook cambiano in base al ramo: le release 1.6/1.7 più vecchie usano flussi diversi per front controller e form rispetto alla 8/9, quindi un modulo ben costruito si collega a qualunque hook Before validato esista per la tua versione di destinazione (per esempio gli hook di invio per registrazione, form di contatto, accesso e newsletter). Qualunque hook usi, valida il token contro l'endpoint siteverify di Google o hCaptcha e rifiuta la richiesta prima ancora che un account o un messaggio venga creato. Il lato di visualizzazione usa displayCustomerAccountForm, displayCustomerLoginFormAfter e displayHeader/displayFooter per inserire il widget e caricare lo script. Se un modulo renderizza solo il badge ma non mette sotto controllo gli hook Before, un bot che invia POST direttamente lo supera senza ostacoli.

Passaggio 3: verifica che blocchi davvero

Non dare nulla per scontato: testa. Invia ciascun form protetto come un cliente normale per confermare che l'uso legittimo funzioni ancora, poi controlla il pannello del fornitore per confermare che le verifiche vengano registrate. Il guasto di configurazione più comune è un form che sembra protetto, ma il cui hook Before non è collegato: così i bot passano mentre tu pensi di essere coperto.

La scelta del modulo specifico per PrestaShop

Poiché la protezione vive o muore su quegli hook lato server, il modulo che scegli conta più del marchio CAPTCHA. Il nostro modulo mprrecaptcha (da PrestaShop 1.6 a 9) è stato creato esattamente per questo: supporta reCAPTCHA v2, v3 e hCaptcha e, su ogni ramo supportato, si aggancia ai veri hook di invio lato server di quella versione per registrazione, contatto, accesso e newsletter; così un POST diretto di un bot viene validato e rifiutato dal controller, non semplicemente nascosto dalla pagina. Cosa significa per te? Scegli dal pannello di amministrazione quali form proteggere, lasci la fase di pagamento senza attrito e le registrazioni false e lo spam dal form di contatto smettono di arrivare, senza modificare file del tema né toccare il core, quindi la soluzione sopravvive agli aggiornamenti. Espone anche un hook displayGDPRConsent, così lo script CAPTCHA può essere collegato al tuo flusso di consenso, aspetto importante nell'UE (vedi sotto).

Il nodo GDPR che non puoi saltare

reCAPTCHA di Google carica JavaScript di Google e invia ai server Google l'IP del visitatore e dati comportamentali: ai sensi del GDPR è un trattamento che richiede una base giuridica, e diverse autorità europee per la protezione dei dati (tra cui la CNIL francese) lo hanno segnalato. Questo crea una tensione reale per un negozio UE: blocca reCAPTCHA fino al consenso ai cookie e i tuoi form restano non protetti per i visitatori che non acconsentono; caricalo comunque e ti esponi sul piano della conformità. Non esiste una risposta universalmente "corretta": è una valutazione del rischio. Due strade pratiche: collegare CAPTCHA al tuo meccanismo di consenso (l'hook displayGDPRConsent sopra esiste per questo), oppure evitare del tutto il trasferimento di dati a Google usando hCaptcha, che non condivide dati con Google. È solo una parte di un quadro di conformità più ampio; la prospettiva generale per il proprietario del negozio è nella guida alla sicurezza in linguaggio chiaro.

CAPTCHA è uno strato, non tutto il muro

CAPTCHA blocca l'abuso automatizzato dei form: account falsi, spam dai contatti, flood di reimpostazione, rumore da forza bruta. Non blocca tutto, e trattarlo come l'intera difesa è un errore. Bot distribuiti che ruotano gli IP, flood di traffico e attori malevoli che hanno già superato il form richiedono altri strati:

• Blocco di bot dannosi e IP per il traffico che non dovrebbe raggiungere affatto i tuoi form: vedi blocco dei bot dannosi e del traffico indesiderato e ban IP per visitatori problematici.
• Protezione lato amministrazione: CAPTCHA aiuta l'accesso dell'area pubblica, ma il pannello di amministrazione ha bisogno di autenticazione a due fattori e criteri per le password: 2FA e sicurezza amministratore.
• Carico generato dai crawler che nessun CAPTCHA risolve, come il flood di query nella ricerca a faccette: sopravvivere al flood ?q=.
• Se qualcosa passa comunque: il piano operativo per gli incidenti in risposta a una violazione dei dati.

La conclusione onesta: porta CAPTCHA sui form di registrazione, contatto e accesso con un modulo che controlli gli hook Before lato server, lascia stare la fase di pagamento, affronta deliberatamente la questione GDPR e considera il risultato come uno strato solido di un negozio rafforzato, non come il traguardo. Fatto così, il lento deterioramento causato da account falsi e messaggi di assistenza sepolti semplicemente si ferma, e tu recuperi i tuoi dati clienti e la tua casella.

Domande frequenti

Su quali form dovrei davvero mettere CAPTCHA?

Proteggi in base a dove sono i bot, non ovunque. I primi tre sono il form di registrazione (il bersaglio numero uno: è così che cresce la pila di account falsi), il form di contatto (mantiene utilizzabile la casella del Servizio clienti) e il form di accesso (ferma il rumore da forza bruta). Livello successivo: reimpostazione password, iscrizione alla newsletter e recensioni prodotto se usi un modulo recensioni. Lascia stare la fase di pagamento, salvo frodi dimostrate: un CAPTCHA visibile lì aumenta gli abbandoni sulla pagina più preziosa, e se proprio devi intervenire usa solo il punteggio invisibile, mai una casella da spuntare.

reCAPTCHA v2, v3 o hCaptcha: quale dovrei scegliere?

v3 è invisibile e assegna un punteggio al comportamento da 0.0 a 1.0 con una soglia impostata da te; è adatto a form ad alto traffico o sensibili alle conversioni, ma richiede una regolazione attenta per non rifiutare persone reali con punteggi bassi. v2 e hCaptcha mostrano una sfida esplicita, accettabile sui form di contatto e registrazione dove un piccolo clic non pesa troppo. Il punto distintivo di hCaptcha per i negozi UE è che non invia dati a Google. Il modulo mprrecaptcha supporta tutti e tre e ti permette di impostare la soglia del punteggio v3; non passa automaticamente da v3 a v2 sui punteggi al limite, quindi la gestione dei punteggi bassi è una decisione di regolazione e rifiuto.

Il mio form sembra protetto ma lo spam passa ancora: cosa c'è che non va?

Quasi sempre la verifica è decorativa, non applicata. Un bot non compila il form a mano: invia un POST direttamente al controller. Quindi, se il modulo renderizza soltanto il widget nella pagina ma non mette sotto controllo gli hook Before lato server (gli hook di invio per registrazione, contatto, accesso e newsletter), un POST diretto passa oltre. La protezione reale valida il token contro l'endpoint siteverify del fornitore prima che account, messaggio o iscrizione vengano creati. Testalo: invia ciascun form come un cliente normale per confermare che funzioni ancora, poi controlla il pannello del fornitore per verificare che le verifiche vengano registrate.

Perché CAPTCHA "smette di funzionare" dopo che sposto domini o aggiungo www?

Le chiavi reCAPTCHA e hCaptcha sono vincolate al dominio. Se la tua Site Key e la tua Secret Key sono state registrate per un host, non verranno validate su un altro; quindi una voce www / non-www non corrispondente o mancante può rompere la validazione o bloccare invii legittimi. Aggiungi alla chiave sia il dominio www sia quello non-www e registra una coppia di chiavi separata per ogni ambiente (test vs produzione). Conferma anche che il form fallisca in modo chiuso: deve rifiutare gli invii quando il token non viene verificato, non lasciarli passare in silenzio.

Usare Google reCAPTCHA è un problema GDPR per un negozio UE?

È una valutazione di rischio reale, non un sì/no risolto una volta per tutte. reCAPTCHA carica JavaScript di Google e invia a Google l'IP e il comportamento del visitatore, cioè un trattamento che richiede una base giuridica ai sensi del GDPR; diverse autorità UE (tra cui la CNIL francese) lo hanno segnalato. Due strade pratiche: collegare CAPTCHA al tuo meccanismo di consenso (l'hook displayGDPRConsent esiste per questo), oppure evitare del tutto il trasferimento di dati a Google usando hCaptcha. Qualunque scelta tu faccia, non caricare mai lo script CAPTCHA prima del consenso se lo tratti come non essenziale.

CAPTCHA sostituisce le altre misure di sicurezza?

No: è uno strato. CAPTCHA blocca gli abusi automatizzati dei form: account falsi, spam dai contatti, flood di email di reimpostazione, rumore da forza bruta. Non blocca bot distribuiti che ruotano gli IP, flood di traffico o chiunque abbia già superato il form. Affiancalo al blocco di bot dannosi e IP per il traffico che non dovrebbe raggiungere affatto i tuoi form, all'autenticazione a due fattori e a criteri per le password per il pannello di amministrazione, e a un piano di risposta agli incidenti se qualcosa passa comunque. CAPTCHA su registrazione, contatto e accesso è uno strato solido di un negozio rafforzato, non il traguardo.