Protezione dai bot, limiti delle richieste e CAPTCHA in PrestaShop

Come procederemmo

Identificheremmo il percorso che non funziona e le richieste che lo causano prima di installare un altro livello di protezione. Il percorso adatto dipende dal negozio esistente: versioni di PrestaShop e PHP, configurazione di hosting e proxy, tema, moduli, integrazioni, dati registrati, mercati e persone che esamineranno i rifiuti. Mantieni i controlli funzionanti e verifica se un modulo installato offre già il passaggio mancante.

Per un negozio che fatica a servire le pagine, parti da dove le richieste possono essere fermate prima di PHP. Per invii indesiderati senza problemi di capacità, parti dal modulo interessato e dalla sua validazione lato server. Per un account o un ordine contestato, esamina le prove prima di limitare l'accesso. La tabella decisionale sotto ti aiuta a scegliere il livello iniziale.

Riproduci i percorsi pertinenti su una copia di staging privata con tema, checkout e moduli reali, isolata da email ai clienti, pagamenti reali ed esportazioni per l'evasione. Salva la configurazione attuale, prova i test di rifiuto e recupero, poi introduci la modifica in una finestra di produzione concordata. Usa una prova circoscritta in produzione per controllare indirizzi proxy effettivi, traffico dei crawler e comportamento perimetrale non riproducibili sullo staging, con un revisore nominato e una procedura per annullare la regola.

Se ti serve una valutazione dell'esposizione, il PrestaShop Security Audit & Hardening Report offre risultati in ordine di priorità e un piano di correzione; l'implementazione ha un ambito separato.

Identifica le richieste prima di bloccarle

Parti dall'azione interessata: pagine di categoria lente, accessi ripetuti, registrazioni false, messaggi spam o crescita dei carrelli vuoti. Registra timestamp, percorsi, argomenti delle query, codici di stato, tempi di risposta e indirizzi di rete coinvolti. Confrontali con worker PHP, attività del database e ordini legittimi.

Crawler dei motori di ricerca, servizi di anteprima dei link social, callback di pagamento, monitoraggio e attività pianificate possono essere automazioni utili. Scraping, tentativi con credenziali sottratte, scansioni di vulnerabilità, account falsi e invii abusivi richiedono controlli diversi. Uno user agent dichiarato, un indirizzo VPN, una rete di hosting o un paese non sono prove di abuso.

Usa i log delle richieste per misurarne la frequenza

Esamina i log del server web e del servizio perimetrale. Per un log di accesso convenzionale in formato combined, questi esempi contano le richieste registrate in base al primo campo indirizzo e al percorso richiesto. Conferma prima il formato effettivo del log; un indirizzo proxy nel primo campo richiede una gestione diversa.

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

Questi totali coprono il file, non un intervallo di frequenza definito. Filtra una finestra temporale adeguata e separa risorse statiche, richieste di pagine, invii di moduli e nuovi tentativi prima di scegliere i limiti. Scansioni generiche come /wp-login.php o /.env meritano un'indagine, ma non dimostrano un'intrusione riuscita.

Le statistiche native possono fornire indizi, secondo i moduli statistici installati. In Statistiche, esamina i pannelli disponibili Visitatori online, Origine dei visitatori, Pagine non trovate e Pagine più viste per individuare variazioni da seguire nei log delle richieste. La tabella delle connessioni non è un log HTTP completo: i bot riconosciuti possono essere esclusi e le registrazioni delle connessioni sono riutilizzate entro una finestra di 30 minuti. La seguente query in sola lettura conta le sessioni di connessione IPv4 registrate per il negozio 1, usando il prefisso di esempio ps_.

SELECT INET_NTOA(c.ip_address) AS recorded_ipv4,
       COUNT(*) AS recorded_sessions
FROM ps_connections AS c
WHERE c.id_shop = 1
  AND c.date_add > DATE_SUB(NOW(), INTERVAL 1 DAY)
GROUP BY c.ip_address
ORDER BY recorded_sessions DESC
LIMIT 50;

Modifica prefisso delle tabelle e ambito del negozio per adattarli alla tua installazione. Esegui report in sola lettura tramite Parametri avanzati > Database > Gestore SQL o uno strumento database autorizzato. Questa memorizzazione numerica legacy degli IP non è un report completo del traffico IPv6. I metadati del browser analizzati nelle tabelle degli ospiti non sono un log User-Agent grezzo.

Anche le tabelle dei visitatori di terze parti possono deduplicare le osservazioni. Contare quelle righe misura i record raccolti, non richieste, visite o un'impronta affidabile del dispositivo. Correlale con i log delle richieste prima di agire.

Trasforma i segnali d'allarme in una diagnosi verificabile

Conserva un breve registro dell'incidente con un esempio di richiesta depurato dai dati sensibili, il relativo fuso orario, la rotta interessata e l'effetto osservato. Fornisci a hosting e sviluppatore lo stesso intervallo affinché possano confrontare eventi perimetrali, log di accesso e attività applicativa senza scambiarsi intere registrazioni dei clienti.

Verifica l'identità dei crawler e gli indirizzi dei proxy

Un bot può inviare Googlebot nel proprio User-Agent. Per esentare un crawler, confronta gli intervalli IP pubblicati e aggiornati pertinenti oppure usa DNS inverso confermato da risoluzione diretta.

1. Ricava l'IP originale del client da un campo affidabile del log.
2. Esegui la risoluzione DNS inversa.
3. Controlla il suffisso di dominio documentato dall'operatore rispettando un vero confine di dominio. Un hostname che termina con googlebot.com.example.net non appartiene a Google.
4. Risolvi in modo diretto l'hostname restituito e verifica che l'indirizzo originale sia tra i risultati.
5. Memorizza in cache e aggiorna i dati di verifica e gestisci gli errori di ricerca senza creare silenziosamente un'esenzione permanente.

Usa la procedura Google per verificare i crawler per le categorie di crawler e i file aggiornati degli intervalli. Gli altri operatori hanno procedure proprie. La verifica stabilisce l'identità, non una capacità di rendering illimitata.

Configura i reverse proxy attendibili prima di abilitare limiti per IP. Il server di origine deve accettare gli header di inoltro dell'indirizzo client solo da infrastrutture attendibili, che devono sovrascrivere i valori in ingresso non affidabili. La validazione sintattica dell'IP non autentica CF-Connecting-IP, X-Real-IP o X-Forwarded-For.

Verifica l'indirizzo visto dal servizio perimetrale, dal server web, da PHP e dalla tua integrazione di blocco. Controlla sia IPv4 sia IPv6. Una configurazione errata può raggruppare tutti i clienti sotto l'indirizzo di un proxy o consentire ai client di scegliere l'indirizzo registrato.

Per le regole per paese, conferma come viene ottenuta la posizione. Un header del paese proveniente da un servizio perimetrale attendibile, un adattatore GeoIP aggiornato e un cookie di paese memorizzato hanno affidabilità diverse. Non presumere che un'API GeoIP legacy funzioni con codice GeoIP2 moderno.

Scegli i controlli al livello giusto

PrestaShop può generare robots.txt in Parametri negozio > Traffico & SEO > SEO & URL. Esamina il contenuto generato e i tuoi percorsi effettivi. Non inserire segreti in robots.txt e non considerare privato un percorso vietato. L'inclusione nella sitemap dipende dal modulo sitemap e dalla sua configurazione.

Includi nell'inventario delle rotte webhook di pagamento, convalida ordini, ritorni 3-D Secure e monitoraggio. Registra scopo, metodo, risposta attesa e responsabile di ogni rotta prima di modificarne il trattamento. Verifica le firme dei fornitori e i requisiti attuali di consegna. Un'esenzione ampia per chiunque dichiari di essere un client di pagamento non è sicura.

Un limite di frequenza deve usare un intervallo temporale esplicito e un carico misurato. Configura uno stato di rifiuto adatto, normalmente HTTP 429 per la limitazione, e una risposta utile per riprovare. Considera reti aziendali, operatori mobili, strumenti di accessibilità e client automatizzati legittimi. Conta l'azione che intendi limitare: includere immagini prodotto e script in una regola di accesso può far consumare il limite a un normale caricamento di pagina. Il traffico distribuito può inoltre sovraccaricare una rotta mentre ogni indirizzo resta sotto il limite individuale.

Per limiti applicativi, attività di aggiornamento dei crawler verificati, verifiche JavaScript e protezione indipendente della capacità, usa la guida di Security Revolution; il suo firewall delle richieste è inizialmente in modalità monitoraggio, quindi attivare una funzione da sola non ne dimostra l'applicazione effettiva.

Contieni le richieste costose della ricerca a faccette

Una richiesta di categoria come /category-slug?q=Brand-Brand-A/Color-Red può attivare un'elaborazione dei filtri. Molte combinazioni distinte possono produrre poco riutilizzo della cache, occupando worker PHP e connessioni al database. Conferma il costo nei tuoi log e profili delle richieste.

Disabilitare ps_facetedsearch può rimuoverne l'interfaccia e ridurre il lavoro di filtraggio. Non impedisce ai client di richiedere URL già noti né a tali richieste di raggiungere il controller di categoria. Un blocco indiscriminato di ogni argomento q può compromettere anche ricerca, percorsi dei moduli, API e filtri salvati dai clienti.

Esempio pratico: server occupato, vendite invariate

Supponi che i log mostrino combinazioni variabili di marca e colore su una categoria mentre i worker PHP restano occupati. Raggruppa le richieste per categoria oltre che per URL completo: un lungo elenco di URL diversi può nascondere una rotta costosa comune. Confronta risposte filtrate e non filtrate e chiedi all'hosting dove viene impiegato il tempo. Se le combinazioni si ripetono raramente, aggiungere ogni risposta alla cache di pagina può aumentare spazio occupato e scritture senza molto riutilizzo.

Prova la regola su quella categoria confermata, mantenendo come controlli un link filtrato diretto rappresentativo e una normale sessione di filtraggio nel browser. Se le verifiche perimetrali aumentano ma il lavoro all'origine resta alto, esamina le richieste che passano ancora: crawler verificati, client che usano l'indicatore AJAX, verifiche superate o traffico diretto all'origine. Queste prove determinano la modifica successiva; un maggior numero di verifiche da solo non dimostra che il collo di bottiglia sia scomparso.

Crea una regola perimetrale con ambito ristretto

1. Elenca i percorsi effettivi delle categorie con faccette, comprese sottodirectory del negozio, lingue e percorsi riscritti. Parti da un piccolo insieme esplicito.
2. Intercetta le richieste GET che contengono l'argomento di faccetta pertinente. Prova anche argomenti vuoti e valori ripetuti.
3. Decidi come trattare i crawler verificati all'interno di questa specifica regola. Non creare un'esenzione ampia per regole di sicurezza non correlate.
4. Controlla il filtraggio AJAX. Restituire una pagina HTML di verifica a una richiesta che si aspetta JSON può interrompere l'interfaccia.
5. Prova Managed Challenge ed esamina il comportamento dei clienti e il carico residuo sull'origine prima di ampliare la copertura.

Questa espressione illustra un negozio il cui percorso di categoria confermato è esattamente /en/12-home-accessories. Usa solo percorsi verificati per il tuo negozio. Se le faccette sono codificate in un percorso riscritto anziché in un argomento q, questa espressione non le intercetta; costruisci e prova una condizione di corrispondenza per quelle rotte effettive.

http.request.method eq "GET"
and http.request.uri.path eq "/en/12-home-accessories"
and len(http.request.uri.args["q"]) >= 0
and not cf.client.bot
and not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest")

Il confronto con chiave mancante restituisce false quando q è assente. Consulta il comportamento dei valori nel linguaggio delle regole Cloudflare. L'indicatore AJAX è falsificabile e alcuni client AJAX legittimi lo omettono. Qualsiasi eccezione basata su di esso lascia una possibilità di aggiramento. Anche un'eccezione per i bot verificati lascia che il carico di quel crawler raggiunga l'origine.

Le regole personalizzate e Managed Challenge sono disponibili su tutti i piani Cloudflare. Le espressioni regolari richiedono Business o Enterprise; l'azione Log delle regole personalizzate richiede Enterprise. Consulta la disponibilità delle regole personalizzate. Senza Log, usa le analisi disponibili e una prova controllata con ambito ristretto.

Usa cf.bot_management.score solo con l'abilitazione Bot Management. Una possibile prova riguarda punteggi superiori a 1 e inferiori a 30; tratta separatamente il punteggio 1 se opportuno. I punteggi descrivono l'automazione, non l'intento malevolo. Il vecchio punteggio di minaccia non è un sostituto. Verifica le interazioni tra le funzioni Cloudflare prima di combinare i controlli. Bot Fight Mode gratuito agisce sull'intero dominio e non può essere escluso tramite regole personalizzate.

Le verifiche possono richiedere interazione, cookie o JavaScript. Prova link diretti, browser mobili e strumenti per la privacy. I visitatori che superano una verifica possono comunque generare lavoro sull'origine.

Impedisci l'accesso diretto che aggira la protezione perimetrale

Instrada i nomi host web pubblici attraverso il proxy del servizio perimetrale scelto. Mantieni i record DNS di posta e degli altri servizi non HTTP configurati per il servizio effettivo. Controlla i record che rivelano l'origine web e limita l'accesso HTTP/HTTPS all'origine agli indirizzi pubblicati e aggiornati del servizio perimetrale, più accessi operativi strettamente giustificati. Preserva rinnovo dei certificati, controlli di integrità e accesso per il ripristino. Usa HTTPS valido tra servizio perimetrale e origine.

Rivedi accesso dei crawler, visibilità nella ricerca e accessi utili da altri siti dopo le modifiche. Se il filtro esistente funziona per gli acquirenti, mantienilo mentre convalidi i controlli del traffico. Considera un'architettura di filtri diversa quando anche la navigazione del catalogo richiede una revisione, con pagine di destinazione scelte deliberatamente al posto di combinazioni arbitrarie indicizzabili. Può ridurre la scoperta di combinazioni arbitrarie, ma vecchi URL ed endpoint AJAX richiedono comunque controlli; usa la guida di Filter Revolution per instradamento e flusso delle pagine SEO del modulo.

Proteggi il server di origine senza un WAF perimetrale

Usa limiti server quando controlli Apache o Nginx, oppure chiedi al tuo hosting di applicarli. Apache .htaccess supporta condizioni adeguate sulle richieste quando gli override sono consentiti; moduli di limitazione come mod_evasive richiedono la configurazione supportata a livello server o virtual host. I blocchi User-Agent possono esprimere una politica sui crawler, ma agenti vuoti o con nomi specifici non sono intrinsecamente malevoli.

In Nginx, limit_req_zone appartiene al contesto http. Applica limit_req dove la richiesta costosa viene effettivamente elaborata. Gli URL semplificati possono reindirizzare internamente a index.php, quindi verifica la location finale e gli argomenti del percorso. I seguenti sono esempi di direttive da integrare in una configurazione esistente, non un blocco server sostitutivo completo:

# http context: illustrative measured-policy starting point
limit_req_zone $binary_remote_addr zone=shop_requests:20m rate=10r/s;

# In the applicable request-processing context
limit_req zone=shop_requests burst=40;
limit_req_status 429;
limit_req_dry_run on;

Usa il riferimento Nginx sulla limitazione delle richieste per verificare supporto ed ereditarietà delle direttive. Con limit_req_dry_run on, le richieste eccedenti vengono registrate ma non rifiutate. Dopo aver controllato log e percorsi legittimi, imposta limit_req_dry_run off, esegui un test della configurazione e ricarica solo una configurazione valida, conservando la precedente per il ripristino. Le rotte di accesso e dei filtri costosi possono richiedere regole separate; una regex per /search non copre tutte le richieste di categoria con q.

Per fail2ban, registra un evento esplicito di autenticazione fallita lato server e prova il filtro con accessi reali falliti e riusciti. Includi un normale errore di password seguito da un nuovo tentativo riuscito e conferma come una persona autorizzata rimuove un blocco errato. L'accesso nativo dei clienti può restituire un modulo di errore con HTTP 200. Un filtro che cerca solo POST di accesso con risposta 401 o 403 può non rilevare gli errori. Non registrare mai password o segreti CAPTCHA.

Un reindirizzamento applicativo circoscritto come ripiego

Se un URL diretto di faccetta selezionato deve portare alla categoria senza filtri, uno sviluppatore può implementare un reindirizzamento anticipato nel Dispatcher. Avvia comunque PHP ed è meno utile contro l'esaurimento delle connessioni rispetto a un controllo perimetrale o server.

1. Individua o associa esplicitamente la categoria per il negozio e la lingua correnti. Limita l'intervento alle richieste GET con l'argomento di faccetta pertinente.
2. Escludi ricerca e percorsi di moduli/API. Se preservi le richieste AJAX, verifica l'indicatore effettivo e accetta che i bot possano copiarlo.
3. Analizza REQUEST_URI, rimuovi solo q e ricostruisci la query con http_build_query(). Conserva gli altri argomenti, il percorso di base del negozio e il prefisso della lingua.
4. Usa l'origine configurata del negozio, impedisci i cicli e interrompi l'elaborazione dopo il reindirizzamento. Altrimenti prosegui con il normale dispatch.
5. Prova con un reindirizzamento temporaneo. Usa un 301 permanente solo se la rimozione della destinazione filtrata è intenzionale. Esamina gli override Dispatcher esistenti e ricostruisci l'indice delle classi pertinente dopo la distribuzione.

I link salvati perdono i filtri selezionati all'interno di quell'ambito. Esamina le pagine filtrate indicizzate che hanno valore e mappale deliberatamente anziché presumere che ogni combinazione non abbia valore di ricerca. Combinare un reindirizzamento con una regola perimetrale rimuove comunque il filtro dopo che un client viene ammesso.

Proteggi i moduli con validazione lato server

Scegli i moduli in base agli abusi osservati: registrazione, contatto, accesso, reimpostazione password, newsletter, recensioni o checkout. Anche ricerca e aggiunta al carrello possono subire abusi di risorse, ma un CAPTCHA interattivo non è automaticamente il rimedio giusto.

I moduli standard non includono tutti un CAPTCHA, ma non sono privi di controlli. Il recupero password include controlli temporali; alcune versioni del modulo di contatto ufficiale usano un honeypot e un token con scadenza. Mantieni questi controlli quando aggiungi un altro livello. Prova compilazione automatica del browser e strumenti assistivi con ogni honeypot aggiunto: un campo nascosto compilato richiede una verifica, non supposizioni su chi l'ha inviato.

Seleziona fornitore e modalità, crea le chiavi corrispondenti nella console del fornitore e inseriscile nella configurazione del modulo. Attiva la protezione per i moduli previsti, poi esegui i test di invio valido e rifiuto qui sotto. La chiave del sito è pubblica; conserva il segreto sul server. Usa tipo di chiave, ambiente e configurazione degli hostname corretti. Registrare un dominio principale reCAPTCHA copre quel dominio e i suoi sottodomini di primo livello, incluso www; domini non correlati richiedono una propria configurazione consentita. Segui le regole di Google sui domini e quelle separate degli altri fornitori.

Il server deve verificare il token e il contesto atteso prima di creare un account, inviare email, iscrivere un indirizzo o autenticare un cliente. Controlla esito, hostname, azione e punteggio ove applicabile. Non fidarti mai soltanto di un indicatore di successo lato client o di un badge visualizzato.

Mantieni separati i requisiti di accesso dei clienti e dei dipendenti. Una verifica funzionante nel front office non dice nulla sull'accesso al back office; l'autenticazione del personale richiede controlli e procedura di recupero propri.

Per gli sviluppatori, verifica l'esatto contratto del core per ogni versione supportata. La registrazione moderna combina i risultati di actionSubmitAccountBefore come booleani. L'accesso nativo dei clienti chiama actionAuthenticationBefore ma non usa il suo valore restituito come rifiuto. Registrare soltanto un hook dal nome simile non basta. Accesso al checkout, registrazione ospite, moduli AJAX e temi personalizzati richiedono una copertura propria dei percorsi.

La registrazione nativa dell'account non richiede generalmente un link di attivazione email. Email di benvenuto, verifica dell'account e doppia conferma della newsletter sono flussi separati.

Per impostazioni dei fornitori, moduli supportati, ripiego facoltativo da v3 a v2 e caricamento condizionale degli script, usa la guida di reCAPTCHA & hCaptcha Protection. La copertura elencata comprende contatto, accesso clienti, registrazione e newsletter, selezionati separatamente; queste opzioni non certificano ogni integrazione di checkout, reimpostazione password o recensioni. Il ripiego elencato mostra una casella di controllo al tentativo successivo a un punteggio basso e richiede una coppia separata di chiavi di ripiego. Verifica che la versione installata lo offra e che il cliente possa completare quel tentativo successivo.

Esempio pratico: registrazione protetta, ma account falsi ancora presenti

Supponi che il modulo autonomo dell'account rifiuti un token mancante, ma continuino a comparire nuovi account spazzatura. Traccia una creazione campione fino alla sua rotta effettiva. Un checkout personalizzato può inviare dati ospite o account tramite un altro endpoint, mentre un importatore o un'integrazione può creare clienti senza usare il modulo pubblico di registrazione. Conferma il comportamento previsto di quella rotta anziché alzare la soglia del punteggio su un modulo diverso.

Per lo spam di contatto, distingui allo stesso modo tra messaggi creati tramite il modulo del negozio e spam inviato direttamente alla casella email. Una verifica sul modulo non intercetta email dirette. Una volta identificata la rotta, ripeti lì sia un invio valido sia un test di rifiuto, controllando il cliente, il messaggio o la coda email risultanti.

Prova rifiuti, interruzioni e clienti legittimi

Esegui la seguente matrice in staging per ogni modulo previsto e ogni percorso supportato. Usa account di prova e sistemi di intercettazione delle email, verificando gli effetti collaterali oltre alla risposta visibile.

Prova con tastiera, lettore di schermo, connessione mobile e strumenti per la privacy. Conserva i dati inseriti dove sicuro e fornisci un canale di contatto utile, come l'assistenza mypresta.rocks per problemi con i suoi moduli.

Regola i punteggi in base alla distribuzione per azione, agli abusi e ai tassi di completamento legittimi del tuo sito. Una soglia come 0,5 è un valore di prova, non un'impostazione universalmente sicura. Non presumere che un browser, una VPN o una velocità di digitazione specifici spieghino un punteggio basso.

Misura le richieste al fornitore e le risorse trasferite in un browser prima di scegliere le regole di caricamento. Il caricamento globale può aggiungere lavoro a pagine senza moduli protetti; quello condizionale deve comunque coprire moduli nel piè di pagina, finestre modali e moduli inseriti tramite AJAX. Non esistono un peso JavaScript fisso o un miglioramento delle conversioni validi per ogni configurazione.

Monitora moduli inviati, rifiuti lato server, falsi positivi, risultati dello spam e completamento degli ordini su periodi comparabili. Separa visualizzazioni dei moduli, tentativi, invii accettati e risultati indesiderati dove la reportistica lo supporta e annota campagne o altri cambiamenti nella composizione dei clienti. Un calo o aumento dello spam da solo non dimostra che l'integrazione sia corretta. Se i controlli del fornitore vengono superati ma i messaggi accettati sono ancora indesiderati, esamina contenuto e schema degli invii; una verifica superata non garantisce una richiesta utile.

Usa restrizioni dei visitatori e conservazione proporzionate

Una restrizione IP riguarda un indirizzo di rete, non una persona. Uffici, università, reti mobili, VPN e proxy possono servire clienti non correlati. Un visitatore abusivo può cambiare indirizzo. I metadati del browser non sono né un'identificazione univoca né la prova che gli account appartengano alla stessa persona.

Usa l'azione, la scadenza e l'intervallo di indirizzi più circoscritti adatti. Un indirizzo esatto è più ristretto di 203.0.113.0/24; un carattere jolly o un intervallo arbitrario può coinvolgere molti visitatori. Verifica il supporto IPv6 dell'integrazione prima di presumere che si applichino le sue regole di corrispondenza IPv4.

Una restrizione del checkout può includere percorsi del carrello, mentre una restrizione di autenticazione può coprire pagine di account, identità e password. Percorsi di checkout e pagamento personalizzati possono comportarsi diversamente. Prova utenti bloccati e consentiti dall'inizio alla fine e mantieni un accesso operativo verificato per il team e il monitoraggio.

Conferma modulo visitatori e schema installati prima di interrogare le tabelle mprvc_*. Per impostazioni specifiche di metadati, restrizioni, campi e scadenze, usa la guida di Customer Extra Info (IP Ban); la scadenza del blocco disattiva una restrizione e non cancella di per sé la registrazione.

Documenta finalità, motivo, revisore e periodo di conservazione. Raccogli solo ciò che serve e distingui i campi opzionali dai dati sempre registrati dall'integrazione. Rimuovi le informazioni obsolete mediante un processo di conservazione deliberato, mantenendo le prove degli incidenti dove richiesto.

Un paese fuori dalla tua area di consegna non giustifica automaticamente il rifiuto dell'accesso al sito. Le regole UE limitano restrizioni e reindirizzamenti basati su nazionalità e residenza; applica misure di sicurezza lecite e proporzionate ed esamina ordini esistenti e obblighi contrattuali. Consulta il Regolamento (UE) 2018/302.

Esempio pratico: un ufficio condivide l'indirizzo che vuoi bloccare

Se registrazioni false ripetute provengono da un indirizzo usato anche da un cliente aziendale legittimo, confronta orari di creazione e percorsi delle richieste prima di agire. Preferisci una regola sull'azione di registrazione abusata a una restrizione dell'intero negozio, dove l'integrazione lo permette. Verifica cosa copre effettivamente una regola di autenticazione: potrebbe impedire anche accesso o recupero password di quel cliente. Prova il percorso di un collega autorizzato oltre alla richiesta indesiderata, imposta una data di revisione e spiega all'assistenza come segnalare un rifiuto errato.

L'accesso in manutenzione è un controllo diverso

L'elenco degli IP consentiti in Parametri negozio > Generale > Manutenzione permette ai visitatori elencati di accedere a un negozio in modalità manutenzione. Non è un elenco di blocco per escludere un responsabile di abusi da una vetrina altrimenti aperta. Usa il controllo il cui ambito corrisponde all'azione che intendi limitare.

Consenso e privacy del fornitore

La CNIL distingue le operazioni CAPTCHA dedicate solo alla sicurezza da quelle che servono anche ulteriori finalità che richiedono consenso. Quando serve il consenso, il rifiuto non deve creare un aggiramento della sicurezza: offri un controllo alternativo o complementare che non richieda quel consenso. Cambiare fornitore da solo non risolve gli obblighi di protezione dei dati e trasferimento internazionale. Segui le indicazioni CNIL sui CAPTCHA, domanda 17.

Un hook chiamato displayGDPRConsent può essere un punto di inserimento del widget. Il suo nome non dimostra che il caricamento sia subordinato al consenso. Controlla le richieste degli script prima del consenso, dopo il rifiuto e dopo la revoca e prova anche il percorso server.

Gestisci i carrelli vuoti e valuta il risultato

Un GET di categoria non salva automaticamente un carrello per ogni visitatore. L'elaborazione nativa di aggiunta al carrello controlla prima prodotti e quantità. Un'aggiunta valida al carrello, un modulo o un altro flusso di sessione possono creare un carrello; un errore successivo può lasciarlo vuoto. Carrelli anonimi o vuoti da soli non dimostrano attività di bot o vendite perse.

Correla gli orari di creazione dei carrelli con le richieste e identifica il componente che li salva. I controlli del traffico possono ridurre le richieste intercettate, ma non garantiscono che la crescita dei carrelli si arresti né rimuovono i record esistenti.

Usa backup e una pulizia limitata per età che tenga conto delle dipendenze. Conserva carrelli collegati a ordini, carrelli legittimi recuperabili, personalizzazioni, file associati e registrazioni degli incidenti necessarie. Nascondere rumore confermato dalle viste operative è diverso dall'eliminarlo.

Rivedi i limiti dopo modifiche a URL, temi, moduli di pagamento o traffico. Conferma che crawler noti, monitoraggio, callback di pagamento, clienti dietro reti condivise e strumenti di accessibilità funzionino ancora. Osserva insieme richieste rifiutate, falsi positivi, tempi di risposta e capacità di rendering.

I dati storici dei crawler forniscono contesto, non una previsione di capacità. Cloudflare ha misurato una crescita aggregata dei crawler di ricerca/AI del 18% da maggio 2024 a maggio 2025, con un picco ad aprile 2025 del 32% sopra maggio 2024. Nel dettaglio per crawler, le richieste Googlebot sono cresciute del 96% e la sua quota è passata da circa il 30% al 50%; le richieste GPTBot sono cresciute del 305%, passando dal 2,2% al 7,7% di quota. ClaudeBot è diminuito del 46% e Bytespider dell'85%; la quota di PerplexityBot è salita da meno dello 0,01% allo 0,2%. La serie aggregata non ha mostrato una crescita continua. Consulta l'analisi datata di Cloudflare sui crawler. Dimensiona i controlli in base al tuo traffico attuale.

Affianca questo lavoro ad aggiornamenti, autenticazione forte del back office e monitoraggio. Usa la guida alla sicurezza per la lista di controlli più ampia e la guida alla risposta alle violazioni se sospetti un'intrusione.

Avvia una modifica reversibile e consegnala al team

1. Registra la situazione iniziale. Salva rotte interessate, impostazioni attuali e prove del problema. Concorda come deve presentarsi il miglioramento e quali problemi per clienti o integrazioni richiedono il ripristino.
2. Modifica un ambito definito. Prova i test pertinenti sullo staging e conserva la configurazione precedente. Evita di cambiare insieme regola perimetrale, soglia CAPTCHA e restrizioni dei visitatori, perché rende più difficile attribuire un rifiuto.
3. Verifica le differenze in produzione. Conferma hostname reali, chiavi dei fornitori, attendibilità dei proxy, restrizioni dell'origine e funzionalità disponibili nel piano perimetrale prima del passaggio pianificato.
4. Esegui la prova circoscritta in produzione. Usa percorsi cliente controllati e verifiche dei callback supportate dai fornitori. Esamina risposta ed effetto effettivi; una homepage funzionante non dimostra che checkout, accesso o webhook funzionino ancora.
5. Esamina entrambi gli esiti. Confronta lavoro residuo all'origine e invii indesiderati con completamenti legittimi e segnalazioni all'assistenza. Se un percorso valido fallisce, annulla la modifica responsabile e indaga sulla richiesta registrata.
6. Lascia una documentazione operativa. Salva ambito finale, eccezioni, revisore, data di revisione e istruzioni di ripristino. Assicurati che un'altra persona autorizzata possa raggiungere il pannello di controllo se l'amministratore abituale è bloccato o assente.

Cosa chiedere al tuo sviluppatore o alla tua agenzia

• Quale componente riceve ciascuna richiesta interessata e quali prove lo collegano al problema?
• Dove viene considerato attendibile l'indirizzo originale del client e un header in ingresso può cambiare l'indirizzo registrato o bloccato?
• Quali rotte ed effetti sono stati testati sulle versioni installate di tema, checkout e moduli, inclusi invii diretti e guasto del fornitore?
• Quali client automatizzati e clienti su reti condivise sono stati verificati e quale carico resta fuori dalla regola?
• Chi può annullare la modifica, dove sono i risultati depurati dai dati sensibili e quali cambiamenti futuri a rotte o integrazioni richiedono un altro test?

Domande dei titolari

Il mio hosting consiglia un server più potente. Devo accettare?

Chiedi prove del collo di bottiglia e delle richieste che lo causano. Una maggiore capacità può essere giustificata dalla domanda legittima, ma confronta il carico residuo dopo una prova circoscritta sul traffico. Un server più grande da solo lascia disponibili le rotte indesiderate.

Perché un cliente ha problemi solo sul telefono?

Chiedi ora, pagina interessata ed errore visibile senza raccogliere password o token. Traccia quel tentativo attraverso servizio perimetrale, server e integrazione del modulo, poi riproduci il percorso con browser mobile e connessione pertinenti. Cambiare ogni impostazione di protezione prima di identificare il livello che rifiuta può nascondere la causa.

Possiamo provare la protezione sommergendo di richieste il checkout reale?

Usa un piano di test concordato e limitato su un ambiente isolato. Conferma chi controlla il test, quali limiti lo fermano e come restano isolati ordini, email e pagamenti. La convalida in produzione deve usare i percorsi controllati concordati con hosting e fornitori delle integrazioni.

Un CAPTCHA superato significa che un ordine è sicuro da evadere?

No. Verifica la prova configurata sul modulo, non la titolarità di un account, la legittimità del pagamento o il rischio di consegna. Mantieni la verifica degli ordini e dei pagamenti richiesta dalla tua attività prima di rilasciare la merce.