Informazioni extra sui clienti e blocchi IP: proteggere il negozio dai visitatori problematici

La maggior parte dei visitatori è esattamente ciò che sembra. Ma ogni negozio, prima o poi, incontra l'eccezione: il "cliente" che effettua dieci ordini e non paga mai, quello che contesta l'addebito alla banca dopo la consegna del pacco, la persona che si registra ogni volta con una nuova email usa e getta dopo la cancellazione dell'account precedente, il concorrente che accede in silenzio dallo stesso ufficio per controllare i tuoi prezzi. L'area di amministrazione di PrestaShop non ti mostra quasi nulla di tutto questo. Vedi un ordine, un nome, un'email — e niente sulla macchina, sulla rete o sulla cronologia che ci sono dietro. Questa guida spiega come chiudere quell'angolo cieco in due modi: raccogliendo abbastanza informazioni extra su chi visita il sito per riconoscere un visitatore problematico, e tenendo pronto un blocco IP così che, quando lo riconosci, tu possa chiudere la porta senza uno sviluppatore e senza mettere offline l'intero negozio.

Ultimo aggiornamento: giugno 2026.

Che cosa ti dice PrestaShop su un visitatore — e che cosa nasconde

Di base, PrestaShop memorizza nome, email, data di nascita facoltativa e indirizzi inseriti dal cliente durante il pagamento. Registra le connessioni in Statistiche → Visitatori online e nella tabella connections, e associa un IP alle sessioni ospite. Quello che non fa è collegare questi punti al posto tuo. Non esiste una schermata che dica "questo account ha effettuato l'accesso da sei IP diversi in tre Paesi questa settimana" o "questi quattro account condividono lo stesso IP e la stessa impronta del browser". I dati grezzi esistono a frammenti; lo schema che ti permetterebbe di individuare presto una frode non emerge in nessun punto in cui andresti davvero a guardare.

Questa lacuna conta perché gli abusi sono quasi sempre uno schema, non un singolo evento. Un articolo restituito è un cliente. Venti resi da account che risalgono tutti allo stesso IP sono un problema che vuoi vedere al terzo giorno, non dopo la terza lettera di contestazione di addebito dal tuo acquirer. Il primo compito, quindi, è la visibilità — arricchire ciò che sai di ogni visitatore in modo che lo schema diventi leggibile.

Le "informazioni extra" che segnalano davvero un visitatore problematico

"Informazioni extra cliente" non significa per forza un modulo di registrazione più lungo (i moduli più lunghi convertono peggio — ed è un costo reale). Le informazioni che intercettano chi abusa del negozio sono i metadati tecnici che la richiesta porta già con sé, ma che semplicemente non stai registrando. Il nostro modulo Customer Extra Info & IP Ban li raccoglie in modo passivo, visita per visita, e li collega alla scheda cliente così puoi leggerli dalla pagina di amministrazione del cliente:

• Indirizzo IP e Paese — quello reale, non quello del proxy. Dietro Cloudflare o un bilanciatore di carico, la lettura ingenua di PrestaShop spesso registra l'IP della CDN. Il modulo legge CF-Connecting-IP, X-Real-IP e X-Forwarded-For (validandoli singolarmente), così l'indirizzo che blocchi è quello del visitatore, non quello del tuo nodo edge.
• Paese — ricavato dall'intestazione CF-IPCOUNTRY di Cloudflare quando presente, oppure dal database GeoIP di PrestaShop come ripiego. Una serie improvvisa di registrazioni da un Paese in cui non spedisci è già un segnale.
• Browser, sistema operativo e tipo di dispositivo — interpretati dallo user agent. Cinque "clienti diversi" tutti sulla stessa build insolita del browser non sono cinque clienti.
• IP univoci per cliente, con prima visita / ultima visita e conteggio visite — questo è il rilevatore di frodi multi-account. Un account che salta tra una dozzina di IP, o un IP che indossa una dozzina di nomi account, emergono subito in questa vista.

La raccolta è volutamente discreta: deduplica i dati, quindi scrive un solo record per combinazione IP-cliente ogni ora invece di martellare il database a ogni caricamento pagina, e ogni dato (user agent, sistema operativo, browser, risoluzione dello schermo) ha un interruttore indipendente di attivazione/disattivazione, così raccogli esattamente ciò che ti serve e niente che preferiresti non conservare. Che cosa ottieni in pratica? Quando arriva una contestazione, apri il profilo del cliente e vedi tutta la sua impronta — ogni IP, ogni Paese, ogni sessione — invece di tirare a indovinare. È la differenza tra agire sulla base di prove e reagire nel panico.

L'elenco clienti mostra ogni cliente con nome, email, stato e date di registrazione e ultima visita.

Se durante un'indagine devi verificare l'impronta grezza, il modulo la memorizza in ps_mprceiipban_info. Sostituisci il prefisso se il tuo negozio non usa ps_:

SELECT id_customer, ip_address, country_code, browser_name, device_type, date_add
FROM ps_mprceiipban_info
WHERE id_customer = 123
ORDER BY date_add DESC
LIMIT 50;

Bloccare IP in PrestaShop: più preciso di "blocca l'indirizzo"

Il core di PrestaShop non offre un vero strumento per bloccare i visitatori — la allowlist IP della modalità manutenzione in Parametri negozio → Generale → Manutenzione esclude tutti tranne gli IP elencati, cioè l'opposto di ciò che serve per un singolo soggetto problematico. Il blocco, quindi, è esattamente il tipo di funzionalità che aggiunge un modulo. La versione ingenua di un blocco IP — un indirizzo, bloccato ovunque — è anche la meno utile, perché è troppo grossolana e troppo facile da aggirare. Un blocco che merita davvero il suo posto ti dà controllo su quale indirizzo, dove colpisce e per quanto tempo.

Corrispondenza oltre il singolo indirizzo

Chi agisce in mala fede raramente resta su un solo IP statico. Il modulo verifica un blocco rispetto a:

• Un IP esatto — il caso più semplice.
• Un carattere jolly come 203.0.113.* — quando qualcuno continua a tornare da indirizzi vicini nello stesso blocco.
• Un intervallo CIDR come 203.0.113.0/24 — il modo preciso per coprire un'intera sottorete.
• Un intervallo di indirizzi come 203.0.113.10-203.0.113.40 — per una fascia arbitraria.
• Un codice Paese — blocca un'intera origine che non servi, valutata rispetto al Paese GeoIP indicato sopra.
• Uno schema user-agent — una corrispondenza testuale semplice o una regex completa, per un utente abusivo identificabile dalla stringa del client invece che dall'indirizzo.

Scegli dove applicare il blocco

Questa è la parte che trasforma una mazza in un bisturi. Ogni blocco ha un ambito:

Questa separazione è importante per la realtà degli IP dinamici e condivisi: uffici, università e operatori mobili mettono molte persone reali dietro un unico indirizzo pubblico. Un blocco completo su un IP condiviso può costarti ordini autentici senza che tu te ne accorga. Un blocco ristretto al pagamento o all'autenticazione contiene il danno esattamente sull'azione abusata. E poiché l'IP reale del visitatore viene risolto correttamente dietro la tua CDN, stai bloccando la persona, non un vicino casuale.

Imposta una scadenza al blocco — e non chiuderti mai fuori

Altri due controlli impediscono ai blocchi di diventare essi stessi un problema. Ogni blocco può essere temporaneo, con una data e ora di scadenza dopo la quale viene disattivato automaticamente — utile per un blocco di raffreddamento quando un blocco permanente sarebbe eccessivo, e ordinato anche per la conservazione dei dati (torneremo sotto sull'aspetto GDPR). E una lista consentiti vince sempre: qualunque IP o CIDR inserito lì non potrà mai essere bloccato, nemmeno da una regola automatica. Inserisci per primi il tuo ufficio, la connessione del tuo sviluppatore e i servizi di monitoraggio, così un blocco ampio impostato in un momento di rabbia alle 2 di notte non potrà chiudere fuori te per errore.

Ogni riga di blocco mostra affiancati l’ambito, l’indirizzo IP e lo stato attivo.

Gli indirizzi affidabili restano nella whitelist mentre gli ordini segnalati mostrano un punteggio di rischio e un motivo.

Fermare l'abuso automatizzato prima che richieda un blocco

Molto traffico da "visitatore problematico" è uno script, non una persona — e la difesa più pulita è rendere automaticamente costoso l'attacco. Il modulo traccia i tentativi di accesso non riusciti per IP e può bloccare automaticamente un indirizzo che supera una soglia da te impostata (un certo numero di errori dentro una finestra temporale), con un blocco temporaneo di ambito autenticazione invece che permanente. È una risposta mirata al credential stuffing: chi forza le credenziali viene escluso dall'accesso per un'ora dopo, per esempio, dieci errori, mentre un cliente che ha digitato male la password due volte non viene toccato.

Il blocco automatico sui tentativi di accesso falliti è un livello. Il compito più ampio di separare i bot buoni da quelli cattivi — scraper, scanner di vulnerabilità, clic fraudolenti sugli annunci — è una disciplina a sé; ne parliamo in Visitor Control: bloccare bot dannosi e traffico indesiderato. E il passo con il valore più alto per fermare registrazioni false e spam nei moduli alla fonte è una verifica sul modulo stesso — vedi reCAPTCHA per PrestaShop. Quando un soggetto malevolo martella gli URL della ricerca filtrata fino a creare un denial-of-service, la prima linea è la tua CDN, non una lista di blocco in PrestaShop: sopravvivere al flood ?q=.

Dove si inserisce il blocco IP nel rafforzamento complessivo

Sii onesto con te stesso su ciò che un blocco IP può e non può fare. È eccellente contro gli utenti occasionali e distratti — la maggioranza di chi abusa, che non è abbastanza sofisticata da preoccuparsi di una VPN. Non è un perimetro contro un attaccante determinato, che può cambiare indirizzo più velocemente di quanto tu possa bloccarlo. Trattalo come uno strumento ben mirato, non come la tua strategia di sicurezza. La strategia vive nell'insieme:

• La panoramica completa — permessi dei file, cartella admin, header, aggiornamenti — è nella checklist di hardening della sicurezza PrestaShop, con una guida più semplice nella guida in linguaggio chiaro per titolari di negozio.
• La messa in sicurezza della stessa area di amministrazione — gli account amministratore sono il vero premio per un attaccante — è trattata in autenticazione a due fattori, policy password e sicurezza admin.
• Se sei bloccato su una versione che non puoi aggiornare, l'hardening avanzato con patch virtuali è il percorso realistico.
• E se il peggio è già successo, non improvvisare — segui risposta a una violazione dei dati: cosa fare se il tuo negozio viene hackerato.

Il lato legale e della tenuta dei registri

Bloccare un cliente nell'UE è un tuo diritto — puoi rifiutare il servizio — ma i dati che conservi per giustificarlo rientrano nel GDPR. Due conseguenze pratiche. Primo, raccogli in modo proporzionato: per questo ogni campo di metadati nel modulo è un interruttore individuale e i vecchi record possono essere eliminati secondo una pianificazione, così non accumuli impronte dei dispositivi che non usi mai. Secondo, conserva una motivazione chiara per ogni blocco (il modulo registra il motivo e il dipendente che lo ha impostato), così se un cliente bloccato si rivolge alla banca o a un'autorità dei consumatori, puoi mostrare perché è stata applicata la restrizione, non solo che è stata applicata. Se quel cliente presenta in seguito una richiesta di cancellazione ai sensi dell'articolo 17, in generale devi soddisfarla — anche se puoi conservare ciò che è realmente necessario per rivendicazioni legali o adempimenti normativi. Le tue condizioni generali dovrebbero già specificare che gli account possono essere chiusi per violazioni delle regole; è quella clausola a dare fondamento al blocco.

Domande frequenti

Un blocco IP può bloccare per errore clienti reali dietro Cloudflare?

Sì, se blocchi l'indirizzo sbagliato — ed è proprio la trappola dietro una CDN. La lettura ingenua dell'IP in PrestaShop registra spesso l'IP di Cloudflare o del tuo bilanciatore di carico invece di quello del visitatore, quindi un "blocco" può finire sul tuo stesso nodo edge e chiudere fuori tutti. Il modulo legge CF-Connecting-IP, X-Real-IP e X-Forwarded-For (validandoli singolarmente), così l'indirizzo che blocchi è quello del visitatore reale, non quello della tua CDN. Risolvi prima l'IP reale; solo allora un blocco è sicuro.

Perché usare un blocco "pagamento" o "autenticazione" invece di un blocco completo?

Perché uffici, università e operatori mobili mettono molte persone reali dietro un unico IP pubblico, quindi un blocco completo su un indirizzo condiviso può costarti ordini autentici senza che tu te ne accorga. Un blocco con ambito pagamento permette a un mancato pagatore seriale di navigare ma non di effettuare ordini; un blocco con ambito autenticazione ferma la creazione di account falsi e il credential stuffing da una fonte senza bloccare ospiti legittimi su quello stesso IP. Abbina l'ambito all'azione abusata — i blocchi completi servono per abusi evidenti che vuoi eliminare del tutto.

Come fermo gli script di credential stuffing senza bloccare clienti reali che sbagliano a digitare?

Usa il blocco automatico dopo accessi falliti con una soglia sensata. Il modulo conta i tentativi di accesso non riusciti per IP e può applicare automaticamente un blocco temporaneo di ambito autenticazione quando un indirizzo supera, per esempio, dieci errori dentro una finestra temporale — così chi forza le credenziali viene escluso dall'accesso per un'ora, mentre un cliente che ha digitato male la password due volte non viene toccato. È una risposta mirata agli script, non una mazzata indiscriminata. Spam nei moduli e registrazioni false si fermano meglio sul modulo stesso con reCAPTCHA.

Come evito di chiudermi fuori con un blocco ampio?

Costruisci prima la lista consentiti. Una lista consentiti vince sempre — qualunque IP o CIDR inserito lì non potrà mai essere bloccato, nemmeno da una regola automatica — quindi aggiungi il tuo ufficio, la connessione del tuo sviluppatore e i servizi di monitoraggio prima di creare qualunque blocco ampio per Paese o CIDR. In questo modo un blocco esteso impostato in un momento di rabbia alle 2 di notte non potrà chiuderti fuori per errore. Abbinalo a blocchi temporanei (una data e ora di scadenza li disattiva automaticamente) per blocchi di raffreddamento in cui un blocco permanente sarebbe eccessivo.

Bloccare un cliente e conservare i suoi IP è un problema GDPR?

Rifiutare il servizio è un tuo diritto, ma i dati che conservi per giustificarlo rientrano nel GDPR, quindi raccoglili in modo proporzionato. Ogni campo di metadati è un interruttore individuale e i vecchi record possono essere eliminati secondo una pianificazione, così non accumuli impronte dei dispositivi che non usi mai. Mantieni una motivazione chiara per ogni blocco (il modulo registra il motivo e il dipendente che lo ha impostato), così puoi mostrare perché è stata applicata una restrizione se un cliente si rivolge alla banca o a un'autorità dei consumatori. Rispetta le richieste di cancellazione ai sensi dell'articolo 17, conservando solo ciò che è realmente necessario per rivendicazioni legali — e assicurati che le tue condizioni specifichino che gli account possono essere chiusi per violazioni delle regole.

Una porta equilibrata, non una fortezza

Il punto di tutto questo non è accogliere gli acquirenti con sospetto — è gestire un negozio amichevole che conserva in silenzio le prove. La maggior parte dei negozi ha raramente bisogno di bloccare qualcuno. Ma il momento giusto per predisporre questa capacità è prima che serva, non durante la crisi, quando una rete di frode è nel pieno dell'azione e tu stai imparando a usare l'area di amministrazione sotto pressione. Attiva la raccolta dei metadati dei visitatori, così gli schemi diventano visibili. Inserisci prima le tue connessioni nella lista consentiti. Tieni i blocchi IP con ambito e scadenza come uno strumento da usare in pochi secondi — un blocco pagamento per chi non paga, un blocco autenticazione per chi crea account in serie, un blocco completo per chi è davvero abusivo — e lascia che il blocco automatico gestisca da solo gli script di brute force. È questo che Customer Extra Info & IP Ban è pensato per darti: la visibilità per riconoscere un visitatore problematico e un modo preciso e reversibile per fermarlo — tutto dalla tua area di amministrazione, senza bisogno di uno sviluppatore.