Sopravvivere all'ondata di ?q=: come il traffico dei crawler trasforma la ricerca a faccette di PrestaShop in un rischio DoS

Ti svegli con una serie di email dei clienti che chiedono perché il sito fosse giù alle 3 del mattino. Il numero degli ordini è normale, la pagina di errore compare a intermittenza e il pannello di amministrazione sembra a posto. Il provider di hosting invia un grafico: connessioni MySQL inchiodate al limite e tutti i worker PHP-FPM occupati. Nessuna di quelle richieste arrivava da clienti reali.

Se gestisci un negozio PrestaShop con ricerca a faccette (a livelli) e non sei ancora stato colpito da questo schema, quasi certamente lo sarai. La forma del problema è banale, la causa è strutturale e la soluzione giusta non è quella a cui la maggior parte dei titolari di negozio pensa per prima. Questo è un resoconto pratico su come difendersi davvero — in particolare dal flood ?q=: il momento in cui il normale traffico dei crawler trasforma la tua ricerca a faccette in una superficie di denial-of-service auto-inflitta. Questo articolo è l'approfondimento su quella specifica modalità di guasto; se vuoi una visione più ampia, la nostra checklist di hardening della sicurezza PrestaShop è l'hub che collega tutti i livelli.

Ultimo aggiornamento: giugno 2026.

Il sintomo

I log mostrano migliaia di richieste a URL come /category-slug?q=Brand-Brand-A/Brand-Brand-B/Color-Red, ognuno leggermente diverso, provenienti da IP a rotazione e da un mix di user agent dichiarati. Alcuni si presentano come Bingbot, altri come Chrome, altri ancora si dichiarano GPTBot, ClaudeBot o PerplexityBot. L'URL della categoria in sé è legittimo — è la tua stessa ricerca a faccette che espone marca e filtri attributo come parametri query-string — ma il volume e la varietà combinatoria delle richieste non lo sono.

I forum di PrestaShop hanno raccolto segnalazioni di questo schema da parte di titolari di negozi su 1.7.x e 8.x per tutto il 2024 e il 2025. La dinamica è costante: un solo thread documenta titolari che vedevano decine di migliaia di URL ?q= unici scansionati ogni giorno, con il controller che continuava a rispondere anche dopo la disattivazione del modulo ps_facetedsearch.

La prima cosa che la maggior parte dei titolari prova è disattivare il modulo di ricerca a faccette. Non serve. ps_facetedsearch espone l'interfaccia dei filtri nel front office, ma una richiesta GET a /category-slug?q=anything avvia comunque PrestaShop, viene inoltrata al controller della categoria e attraversa il ciclo di vita della richiesta. La query string è una forma di richiesta valida, che il modulo che ha generato quegli URL sia attualmente attivo o meno. Disattivare il modulo nasconde la barra laterale dei filtri ai visitatori umani; non impedisce ai client automatizzati di continuare a colpire URL che hanno già scoperto.

Perché il volume sta crescendo

La natura combinatoria degli URL della ricerca a faccette esiste da quando il modulo è stato rilasciato. La novità è la scala del traffico automatizzato che li trova e li scansiona.

L'analisi di luglio 2025 di Cloudflare sul traffico dei crawler nella sua rete riportava:

• Traffico dei crawler in aumento del 18% anno su anno, con picchi del 32% ad aprile 2025.
• Googlebot: crescita del 96%, passando da circa il 30% al 50% di tutto il traffico di scansione.
• GPTBot: crescita del 305%, dal 2,2% al 7,7% di quota.
• PerplexityBot: da sostanzialmente zero a una presenza significativa in un solo anno.
• ClaudeBot: richieste in calo del 46% dopo le modifiche di inizio 2025.
• Bytespider: in calo dell'85%.

La composizione cambia di mese in mese, ma la tendenza no: più crawler, più URL colpiti, più spesso. Una pagina categoria che genera qualche centinaio di combinazioni di filtri diventa un bersaglio per tutto, da Googlebot che costruisce indici di dati strutturati agli scraper per addestramento AI che raccolgono attributi prodotto. A metà 2025 Cloudflare stessa ha iniziato a bloccare per impostazione predefinita i bot di addestramento AI sulle nuove zone, e questo dice molto su come la piattaforma legge la traiettoria.

Sopra quel traffico legittimo dei crawler c'è uno strato molto più piccolo ma più aggressivo di automazione ostile: scraper, bot di intelligence competitiva e traffico da stress test. Questi non rispettano robots.txt, ruotano gli IP in modo aggressivo e falsificano stringhe user-agent legittime. Sono loro a mandare giù il sito. Fermare questa classe più ampia di automazione indesiderata — non solo il flood ?q= — è una disciplina a sé; trattiamo l'approccio generale in come bloccare bot dannosi e traffico indesiderato.

Perché le soluzioni più ovvie non funzionano

La maggior parte dei consigli nei forum della community rientra in una di cinque categorie. Nessuna è sufficiente da sola.

Disattivare il modulo di ricerca a faccette. Rimuove l'interfaccia, lascia la superficie URL. Il controller della categoria continua a rispondere alle richieste ?q=.

Aggiungere Disallow: /*?q= a robots.txt. Googlebot in gran parte lo rispetta. Bingbot lo rispetta in modo incoerente — ci sono segnalazioni pubbliche di scansioni comunque eseguite su pattern query vietati. I crawler AI rispettano robots.txt con percentuali molto diverse a seconda dell'operatore. Gli scraper ostili lo ignorano del tutto. Utile da fare, mai sufficiente.

Un blocco globale in .htaccess su qualsiasi URL che contenga ?q=. Questo intercetta i bot, ma rompe anche le richieste AJAX dei tuoi stessi filtri (lo stesso pattern URL che il front office usa per recuperare risultati filtrati senza ricaricare la pagina) e rompe ogni URL filtrato che clienti reali hanno salvato nei preferiti o condiviso. Il danno SEO si somma se Google aveva indicizzato una di quelle pagine filtrate come canonica per query di long tail. C'è un posto per regole server rifinite a mano — ma non con un martello pneumatico; le nostre regole .htaccess di sicurezza e prestazioni per PrestaShop coprono quelle che vale la pena mantenere.

Bloccare specifici user-agent dei bot. È una caccia continua. Nuovi bot compaiono ogni settimana, i bot ostili falsificano le stringhe UA e finiresti per bloccare anche i referrer AI legittimi (ChatGPT, Perplexity, Copilot) che portano una quota crescente di clic in ingresso. Il rapporto scansione/clic è ancora scarso per i bot AI, ma non è zero — i dati di Cloudflare mostrano che i referral esistono.

Cache full-page degli URL ?q=. Il tasso di hit della cache è vicino a zero perché ogni combinazione di filtri è un URL unico. Metti in cache 50.000 pagine e servi ciascuna una sola volta. La cache diventa un problema di amplificazione delle scritture invece che una scorciatoia di lettura.

L'opzione restante — e quella di cui parla il resto di questo articolo — è mettere la decisione su chi può colpire quegli URL completamente davanti a PrestaShop, dove può essere presa a basso costo e senza avviare PHP.

La soluzione giusta: un Cloudflare Managed Challenge sulla forma della ricerca a faccette

Il Managed Challenge di Cloudflare è lo strumento giusto per questo problema per tre ragioni. Nella maggior parte dei casi non è interattivo (gli utenti umani lo superano in modo trasparente), non richiede di elencare bot specifici in una lista di blocco e permette di mantenere funzionanti le chiamate AJAX dei filtri del tuo front office, usando una forma di richiesta che l'automazione non può imitare banalmente.

Il pattern prevede due regole personalizzate (con Bot Management a pagamento) o una sola (piano gratuito), valutate su qualsiasi GET che contenga il parametro query q.

Se hai Bot Management (a pagamento)

Regola 1 — salta i bot verificati. Corrispondenza sull'espressione cf.client.bot, con azione impostata su Skip remaining custom rules. Questo lascia passare senza challenge Googlebot, Bingbot e qualsiasi altro crawler verificato da Cloudflare. Il rilevamento dei bot verificati si basa su reverse DNS e intervalli IP firmati, non sulle stringhe user-agent, quindi uno scraper ostile che falsifica "Mozilla/5.0 (compatible; Googlebot/2.1)" non corrisponderà.

Regola 2 — challenge alla probabile automazione sulla forma della ricerca a faccette. L'espressione, scritta attraverso le sue clausole logiche, dice:

• http.request.method eq "GET"
• and len(http.request.uri.args["q"]) >= 0 — la richiesta contiene un parametro q
• and not cf.client.bot — non è un crawler verificato
• and not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest") — non è la chiamata AJAX dei filtri del front office
• and not starts_with(http.request.uri.path, "/module/")
• and not starts_with(http.request.uri.path, "/api/")
• and cf.bot_management.score gt 1 and cf.bot_management.score lt 30 — rientra nella fascia "probabile automazione, ma non ancora certa"

Azione: Managed Challenge. In parole semplici: una richiesta GET che contiene un parametro query q, non è un bot verificato, non è la chiamata AJAX dei filtri del front office (che invia X-Requested-With: XMLHttpRequest), non è un endpoint di modulo o API e ottiene un punteggio da probabile automazione — sottoponila a challenge. Gli utenti umani passano con un clic; l'automazione viene fermata al perimetro.

Se vuoi essere più severo con il traffico chiaramente automatizzato, aggiungi una regola prima della Regola 2 che corrisponda alla stessa forma GET-con-q, non-bot-verificato, ma con cf.bot_management.score eq 1 — la valutazione di Cloudflare per "questa è automazione, punto". Azione: Block (difendibile) oppure Managed Challenge, a seconda della tua propensione al rischio.

Se non hai Bot Management (piano gratuito o Pro)

L'espressione Cloudflare dovrebbe corrispondere alla forma della ricerca a faccette, non a ogni URL di categoria. Parti in modalità log o managed challenge prima di bloccare:

(http.request.uri.query contains "q=" and http.request.uri.path contains "/category")
or
(http.request.uri.path matches "^/[^?]+/q-[^/]+")

Nei piani gratuiti non esiste un punteggio bot equivalente. Il vecchio campo cf.threat_score consigliato dalle guide meno recenti ora è impostato permanentemente a 0 — Cloudflare lo ha deprecato. Non perdere tempo con regole che lo referenziano.

Senza un punteggio bot, ripieghi sulla sola forma della richiesta. Parti in modo conservativo con una singola regola che scatti su: una richiesta GET, dove len(http.request.uri.args["q"]) >= 0, e not cf.client.bot, e la richiesta non è una chiamata AJAX (nessun header X-Requested-With: XMLHttpRequest), e il percorso non inizia con /module/ o /api/. Azione: Managed Challenge.

Questo sottopone a challenge ogni GET non-AJAX e non-bot-verificato che include un parametro q. I clienti reali che aprono un URL filtrato salvato nei preferiti vedono un breve Managed Challenge e lo superano. I link salvati continuano a funzionare. Il traffico dei crawler viene tagliato al perimetro. Il costo è un round-trip in più per i visitatori umani che arrivano su un URL a faccette tramite un segnalibro o un link condiviso.

Avvertenze importanti prima di attivare tutto questo

Testa prima in modalità solo log / Security Events. Imposta l'azione della regola su "Log" per almeno 24–48 ore e osserva la dashboard Security Events di Cloudflare. Devi verificare due cose: che la regola scatti sul traffico previsto (molto), e che non scatti su percorsi legittimi che avevi dimenticato — fetcher di sitemap, strumenti di analytics, un modulo personalizzato che per qualche ragione usa ?q= nei propri URL. Passa a Managed Challenge solo dopo aver confermato che il matcher è pulito.

L'eccezione X-Requested-With preserva la UX, non è un confine di sicurezza. Qualsiasi client HTTP può inviare quell'header. Un attaccante che capisce l'esistenza della regola può aggirarla aggiungendo l'header al proprio scraper. Il motivo per cui è nella regola è lasciare passare senza challenge l'AJAX dei filtri del tuo front office — non tenere fuori l'automazione determinata. I controlli cf.client.bot e sul punteggio bot sono quelli che fermano davvero l'automazione; l'eccezione AJAX mantiene semplicemente gli utenti reali sulla stessa pagina quando cliccano i filtri.

Proxy di ogni hostname web pubblico (orange-cloud) — ma gestisci correttamente posta e record non HTTP. I record Mail/MX e altri record non HTTP in genere non devono passare attraverso il proxy Cloudflare, e il proxy orange-cloud non può proteggere allo stesso modo servizi non HTTP. Il vero rischio è qualsiasi record solo DNS (grey-cloud) — mail, dev, un sottodominio admin — che punti allo stesso server del negozio, perché rivela l'IP dell'origine web. Chiunque trovi l'origine può bypassare completamente Cloudflare e colpire PrestaShop direttamente. Tieni mail e altri record non HTTP solo DNS, ma assicurati che non puntino all'IP dell'origine web e non lo rivelino — sposta mail, dev e admin su IP separati, oppure limitane l'accesso. Verifica il pannello DNS prima di fidarti del WAF.

Limita l'origine agli IP Cloudflare. Anche con tutto proxato, blocca rigidamente l'origine a livello firewall in modo che accetti HTTP/HTTPS solo dagli intervalli IP pubblicati da Cloudflare. Altrimenti un attaccante che scopre l'IP di origine da vecchi storici DNS può colpirlo direttamente. Mentre limiti l'accesso all'origine, assicurati che l'origine sia HTTPS-only end to end — la nostra guida su come configurare SSL e HTTPS su PrestaShop copre certificato e reindirizzamenti, così edge e origine sono allineati.

Se dipendi dai referral della ricerca AI, controlla l'impatto. Alcuni crawler AI fanno anche parte del percorso di referral che porta clienti tramite link da ChatGPT, Perplexity e Copilot. Una challenge globale ridurrà sia il traffico di scansione sia (in misura minore) i referral in ingresso. Il compromesso di solito vale la pena per un sito e-commerce, ma resta un compromesso — controlla le analytics dopo una settimana.

Il fallback: un override del Dispatcher

Se oggi non puoi implementare Cloudflare — perché non controlli il DNS, perché l'integrazione CDN del tuo host è fragile, perché un modulo di pagamento è incompatibile con origini proxate o perché devi semplicemente fermare l'emorragia nei prossimi dieci minuti — il fallback lato PHP è un override del Dispatcher che reindirizza con 301 le richieste non-AJAX ?q= allo stesso URL senza il filtro.

Lo posizioni in override/classes/Dispatcher.php. La classe estende DispatcherCore e sovrascrive dispatch(). La logica: se Tools::getValue('q') è presente e la richiesta non è una chiamata AJAX (la variabile server HTTP_X_REQUESTED_WITH è vuota o diversa da xmlhttprequest), allora analizza $_SERVER['REQUEST_URI'], rimuove la chiave q dai parametri query analizzati, ricostruisce l'URL con http_build_query() rispetto a Tools::getShopDomainSsl(true), invia un header Location 301 verso l'URL ripulito ed esegue exit. Altrimenti restituisce parent::dispatch() senza modifiche.

Cosa fa: qualsiasi richiesta diretta da browser, non-AJAX, a un URL che contiene ?q= viene reindirizzata con 301 allo stesso percorso con il parametro q rimosso. Le richieste AJAX (le chiamate filtro del front office) passano invariate. L'interfaccia dei filtri a faccette continua a funzionare per i clienti reali; la superficie URL che i bot scansionano collassa in una singola pagina categoria canonica. (Un override in override/classes/Dispatcher.php è un punto di estensione supportato da PrestaShop — sopravvive agli aggiornamenti dei moduli, ma ricordati di svuotare la cache class-index dopo aver inserito il file, altrimenti PrestaShop continuerà a caricare la classe core.)

Tre compromessi da capire prima di metterlo in produzione:

• Impatto SEO. Se Google ha indicizzato alcuni dei tuoi URL filtrati come canonici per query di long tail ("scarpe da running blu taglia 42"), quei posizionamenti crollano — ogni URL filtrato indicizzato ora reindirizza alla categoria non filtrata. Per la maggior parte dei negozi è accettabile; gli URL facet originali erano in genere posizionamenti deboli comunque. Ma controlla Search Console prima del deploy e valuta un'esportazione una tantum degli URL filtro ad alto valore che vuoi mantenere, con mappe 301 esplicite verso landing page dedicate.
• Preferiti e condivisioni. Un cliente che ha salvato o condiviso un URL filtrato non atterra più sulla vista filtrata. L'approccio Cloudflare Managed Challenge lo preserva; l'override del Dispatcher no.
• Aiuta solo con il carico lato PHP. La richiesta arriva comunque a PHP — semplicemente esce rapidamente con un 301 invece di eseguire l'intera pagina categoria. Se il tuo collo di bottiglia è il numero di connessioni più che la CPU, aiuta meno della correzione a livello edge.

Distribuiscilo come soluzione tampone. Passa a Cloudflare appena puoi.

Edge contro origine: quale soluzione per quale collo di bottiglia

Le due difese non sono intercambiabili. Scegli in base a dove il tuo negozio sta davvero soffrendo.

Se puoi fare entrambe, falle entrambe: la regola edge sostiene il carico, e l'override è la tua rete di sicurezza nella finestra prima della propagazione DNS o se mai dovessi rimuovere il proxy.

L'angolo architetturale: sostituire la superficie URL stessa

Le pagine filtro indicizzabili dovrebbero essere URL deliberati, non combinazioni accidentali dei crawler.

Entrambe le soluzioni sopra proteggono dall'automazione la superficie URL esistente di ps_facetedsearch. Nessuna cambia il fatto che il modulo espone in partenza uno spazio URL pubblico combinatoriamente enorme.

Un'altra classe di moduli filtro evita il problema alla radice: lo stato del filtro vive lato client (o in una singola POST AJAX), l'URL pubblico resta pulito e diventano indicizzabili solo landing page SEO curate deliberatamente — una pagina costruita a mano per "scarpe da running da uomo" invece di ogni combinazione marca-colore-taglia. Abbiamo costruito Filter Revolution in questo stile, in parte proprio in risposta ai pattern di traffico descritti qui. Quindi cosa significa per te? Riduce la superficie URL pubblica ad alta cardinalità che rende ps_facetedsearch appetibile per i crawler, il che significa meno pagine combinatorie da scoprire per i bot e meno messaggi alle 3 del mattino dal tuo host — configurato dal back office, senza fare fork del tema. Non è uno scudo magico contro i crawler AI — nulla lo è — e non deindicizza retroattivamente gli URL che Google e Bing hanno già trovato. Ma rimuove la superficie d'attacco strutturale aggirata dalle soluzioni Cloudflare e Dispatcher.

Se sei stanco di rattoppare il sintomo e comunque devi rivedere la ricerca a faccette, valuta di sostituire il modulo invece di incapsularlo. Se il modulo attuale è adatto al negozio, la regola Cloudflare sopra continuerà a funzionare a tempo indeterminato.

Un'ultima cosa: i carrelli vuoti

Ogni richiesta bot che colpisce la pagina categoria attiva anche il bootstrap della sessione e del carrello di PrestaShop. Ogni visitatore automatizzato unico ottiene una riga ps_cart. Dopo un mese di traffico crawler, il contatore carrelli nel back office mostra 80.000 carrelli "attivi", le pagine admin legate ai carrelli rallentano fino a diventare quasi inutilizzabili e qualsiasi workflow di carrelli abbandonati diventa impraticabile perché quasi nessuno di quei carrelli è mai stato associato a un essere umano.

Se hai già implementato la regola Cloudflare, la crescita si ferma — ma l'inquinamento esistente non si pulisce da solo, e le attività integrate di pulizia carrelli di PrestaShop non sono abbastanza aggressive per gestire mesi di carrelli bot accumulati. La soluzione pragmatica è nascondere dai contatori e dagli elenchi del back office i carrelli anonimi di origine bot invece di eliminarli: le righe restano nel database per qualsiasi valore forense possano avere, ma smettono di inquinare l'interfaccia. È un problema distinto dal flood stesso e lo trattiamo come un lavoro a parte — se il tuo admin carrelli è già sommerso dai carrelli bot, quella è la pulizia da eseguire insieme alla regola edge, non al suo posto.

Dove si inserisce nelle tue difese più ampie

Il flood ?q= è una modalità di guasto specifica, ma il piano di controllo che costruisci per fermarlo ripaga anche nel resto della postura di sicurezza. Alcuni lavori adiacenti da mettere in fila una volta attivata la regola edge:

• Blocco per visitatore e ban IP. Quando una singola fonte continua a sondare dopo la challenge, vuoi un modo pulito per tagliarla fuori e vedere chi ti sta colpendo — vedi informazioni extra cliente e ban IP.
• Spam nei moduli, separato dai flood di traffico. La stessa automazione che scansiona le faccette martellerà anche i moduli di contatto e registrazione; lì la risposta è una challenge all'invio — vedi reCAPTCHA per PrestaShop.
• Se non puoi ancora aggiornare il core. I negozi bloccati su una versione PrestaShop più vecchia hanno meno leve native; l'approccio edge-più-override qui fa parte di una strategia più ampia di virtual patching in hardening avanzato per negozi che non puoi ancora aggiornare.
• Se tutto questo è nuovo per te. Se la terminologia sopra è tanta, parti dalla guida in linguaggio semplice per titolari di negozio e procedi da lì.

Domande frequenti

Perché disattivare il modulo di ricerca a faccette non ferma il flood ?q=?

Perché ps_facetedsearch espone solo l'interfaccia dei filtri — non possiede la superficie URL. Una richiesta GET a /category-slug?q=anything avvia comunque PrestaShop, viene inoltrata al controller della categoria ed esegue l'intero ciclo di vita della richiesta, che il modulo sia attivo oppure no. Disattivarlo nasconde la barra laterale dei filtri agli utenti umani; non fa nulla per fermare i client automatizzati che colpiscono URL già scoperti.

Un Disallow in robots.txt risolve il flood ?q=?

Aiuta, ma non è mai sufficiente da solo. Disallow blocca la scansione, non l'indicizzazione — e soprattutto solo i crawler ben educati lo rispettano. Googlebot in gran parte lo rispetta, Bingbot lo rispetta in modo incoerente, i crawler AI variano in base all'operatore e gli scraper ostili lo ignorano completamente. Poiché il traffico che manda giù il negozio è la parte che ignora robots.txt, la vera soluzione deve stare all'edge o davanti a PHP. Utile da fare, mai la risposta completa. (Su PrestaShop 9, le pagine a faccette sono escluse dalla sitemap per impostazione predefinita, il che riduce la scoperta ma non impedisce che URL già noti vengano colpiti.)

Perché non bloccare semplicemente in .htaccess qualsiasi URL che contenga ?q=?

Perché un blocco globale è un martello: rompe anche le richieste AJAX dei filtri del tuo front office (stesso pattern URL) e ogni URL filtrato che clienti reali hanno salvato o condiviso. Se Google aveva indicizzato pagine filtro, il danno SEO si somma. Lo strumento giusto sottopone a challenge l'automazione in base alla forma della richiesta all'edge, lasciando passare bot verificati e le tue chiamate AJAX — un Cloudflare Managed Challenge, non un diniego piatto.

Qual è la soluzione più rapida se oggi non posso implementare Cloudflare?

Un override/classes/Dispatcher.php che reindirizza con 301 le richieste non-AJAX ?q= all'URL categoria non filtrato. È un punto di estensione supportato da PrestaShop che sopravvive agli aggiornamenti dei moduli — ricordati di svuotare la cache class-index dopo aver inserito il file, altrimenti PrestaShop continua a caricare la classe core. Riduce solo il carico lato PHP (PHP si avvia comunque, poi esce sul 301) e rimuove gli URL filtro salvati nei preferiti, quindi trattalo come una soluzione tampone da dieci minuti e passa alla correzione edge appena puoi.

Perché questo flood riempie anche la tabella carrelli con migliaia di carrelli vuoti?

Ogni richiesta bot che colpisce una pagina categoria attiva anche il bootstrap della sessione e del carrello di PrestaShop, quindi ogni visitatore automatizzato unico ottiene una riga ps_cart. Dopo un mese puoi vedere decine di migliaia di carrelli "attivi" senza alcun essere umano associato, che rallentano le pagine admin dei carrelli e qualsiasi workflow di carrelli abbandonati. Fermare il flood all'edge arresta la crescita, ma l'inquinamento esistente richiede una pulizia separata e controllata — non aspettarti che le attività carrello integrate di PrestaShop eliminino mesi di accumulo.

Smetti di incapsulare il problema — riduci la superficie

Sia le soluzioni Cloudflare sia quelle Dispatcher proteggono la superficie URL esistente ad alta cardinalità; non la rimuovono. Filter Revolution mantiene lo stato dei filtri lato client, così l'URL pubblico resta pulito e diventano indicizzabili solo landing page SEO curate deliberatamente — meno pagine combinatorie da far scoprire ai crawler in partenza. Insieme alla regola edge, Cleanup Revolution riduce l'inquinamento dei carrelli bot e Security Revolution copre l'hardening più ampio di cui questo flood è solo un angolo.

Checklist rapida

• Attiva Cloudflare per il dominio. Proxa ogni hostname web pubblico (orange-cloud); mantieni mail e altri record non HTTP solo DNS e assicurati che non puntino all'IP dell'origine web né lo rivelino.
• Aggiungi la Regola 1 (salta i bot verificati) e la Regola 2 (Managed Challenge sulla forma a faccette) in modalità solo log. Osserva Security Events per 24–48 ore.
• Conferma che le chiamate AJAX legittime dei filtri non vengano sottoposte a challenge. Conferma che Googlebot raggiunga il sito. Conferma che il traffico degli scraper venga intercettato.
• Passa la Regola 2 da Log a Managed Challenge.
• Limita il firewall dell'origine agli intervalli IP Cloudflare. È questo che chiude il cerchio.
• Se Cloudflare non è un'opzione, implementa l'override del Dispatcher come soluzione tampone e pianifica la migrazione.
• Se devi comunque rivedere il modulo filtri, valuta di sostituire completamente ps_facetedsearch.
• Pulisci separatamente l'inquinamento dei carrelli nel back office, così l'admin carrelli resta utilizzabile.

Conclusione

Questa è la nuova base di partenza. L'esplosione degli URL della ricerca a faccette incontra il volume dei crawler dell'era AI, e il risultato è una superficie DoS auto-inflitta che esce di serie da ogni installazione PrestaShop. Le impostazioni predefinite non ti salveranno, le scorciatoie più ovvie rompono gli utenti legittimi e "bloccare i bot" diventa più difficile ogni mese mentre i bot migliorano.

La buona notizia è che la soluzione giusta vive all'edge, non costa nulla su un piano Cloudflare gratuito e richiede circa trenta minuti per essere implementata con attenzione. La cattiva notizia è che è un'altra cosa che avresti dovuto fare l'anno scorso. La notizia cumulativa è che il lavoro si riutilizza: una volta che hai un'origine pulita dietro un WAF ben tarato, la classe successiva di fastidi automatizzati — credential stuffing, scraping, ondate di finte procedure di acquisto — diventa sensibilmente più facile da difendere dallo stesso piano di controllo.

Per l'approccio completo a livelli, torna alla checklist di hardening della sicurezza PrestaShop. Per cosa succede quando un negozio viene compromesso da qualcosa di più sofisticato dell'abuso dei crawler, leggi l'anatomia di un attacco in stile Magecart su un negozio PrestaShop 1.7.x. Il playbook difensivo ha la stessa forma in entrambi i casi: controlli economici all'edge, eccezioni strette dove devi farle e nessuna affermazione di sicurezza che si regga sulle stringhe user-agent.