Segnali che indicano che il tuo negozio PrestaShop ha bisogno di un audit di sicurezza (e come fare prima un controllo autonomo)
Ultimo aggiornamento: giugno 2026.
La maggior parte dei negozi PrestaShop non ha bisogno di acquistare un prodotto di sicurezza. Ha bisogno di conoscere la propria esposizione reale — e molti titolari, sinceramente, non la conoscono, perché all'apparenza non sta succedendo nulla di strano. Uno skimmer può restare sulla pagina di pagamento per settimane mentre gli ordini continuano ad arrivare normalmente. Un modulo vulnerabile può rimanere senza patch per anni prima che qualcuno lo individui con una scansione. Il senso di una revisione di sicurezza non è creare paura; è sostituire "penso che probabilmente siamo a posto" con una risposta chiara e supportata da prove. Questo articolo mostra i segnali concreti che meritano un controllo più approfondito e ti offre una verifica autonoma da fare in circa dieci minuti prima di decidere se hai davvero bisogno di un aiuto esterno.
I segnali che contano davvero
Non sono ipotesi teoriche. Ognuno di questi casi è qualcosa che abbiamo visto trasformarsi in un incidente reale su negozi reali. Leggili come fattori di rischio: più elementi si applicano al tuo caso, più vale la pena investire tempo in un audit strutturato.
Stai usando una versione vecchia o fuori supporto di PrestaShop
PrestaShop 1.6 è fuori supporto da molto tempo e gran parte del ramo 1.7.x non riceve più correzioni di sicurezza. Anche su 8.x, un'installazione indietro di qualche versione minore può non includere patch per problemi già noti pubblicamente. Un core vecchio è il principale indicatore di esposizione, perché gli attaccanti non devono scoprire una nuova falla: scansionano semplicemente quelle già documentate. Se non sai dire, senza controllare, quale versione esatta stai usando, questo è già un segnale.
I tuoi moduli non vengono aggiornati da anni
Questa è la vera superficie di attacco nella maggior parte dei negozi. Il core riceve attenzione; i moduli di terze parti invecchiano in silenzio. La storia è lunga: la SQL injection in blockwishlist, la server-side template injection (SSTI) basata su Smarty che ha portato all'esecuzione di codice remoto in diversi moduli, e un flusso costante di vulnerabilità meno note. Un modulo installato una volta e poi dimenticato è un punto di ingresso perfetto proprio perché nessuno lo sta controllando. Se l'elenco degli aggiornamenti dei moduli mostra molte operazioni in sospeso, o moduli di fornitori che non esistono più, trattalo come un segnale di allarme.
Il tuo pannello admin è sul percorso predefinito, senza limitazione dei tentativi o 2FA
Un pannello di amministrazione raggiungibile da un URL prevedibile, senza protezione contro i tentativi di forza bruta e senza autenticazione a due fattori, è un invito aperto ai bot che fanno credential stuffing e tentativi di password guessing. Sono attivi continuamente e non devono essere sofisticati: basta una sola password debole o riutilizzata da un account dipendente.
Nessun WAF, e l'IP origin è esposto
Se il tuo negozio è esposto direttamente su Internet senza un web application firewall, ogni richiesta malevola raggiunge il codice della tua applicazione senza filtri. Peggio ancora: se usi una CDN ma il tuo vero IP origin è trapelato (nella cronologia DNS, nelle intestazioni email o in un vecchio sottodominio), gli attaccanti possono aggirare completamente la protezione e colpire direttamente il server.
File inspiegabili, core modificato o account admin che non riconosci
File PHP sparsi nella webroot, file del core diversi da una release pulita, o una voce nell'elenco dei dipendenti che nessuno del team ha creato: ciascuno di questi elementi può indicare che il negozio è già stato compromesso. Le backdoor sono progettate per sembrare innocue e restare silenziose, quindi raramente si fanno notare.
Una pagina di pagamento o un modulo di pagamento che "sembra leggermente diverso"
Questo è il segnale che può costare di più. Gli skimmer in stile Magecart iniettano poche righe di JavaScript che copiano di nascosto i dati della carta mentre i clienti li digitano, poi li inviano al server dell'attaccante. La pagina continua a funzionare. L'ordine viene completato. Solo i dati della carta vengono rubati. Se la pagina di pagamento ti sembra sottilmente diversa — un campo in più, uno spostamento del layout, uno script che non ricordi di aver aggiunto — prendilo sul serio. Abbiamo spiegato esattamente come funziona uno di questi casi nel nostro articolo sull'anatomia di un attacco Magecart su uno skimmer PrestaShop.
Nessun monitoraggio dell'integrità dei file e nessun backup esterno
Se non hai modo di rilevare che un file è cambiato, non puoi distinguere un negozio pulito da uno compromesso — e di solito lo scoprirai da un cliente o dal tuo processore di pagamento. E se gli unici backup si trovano sullo stesso server (o non hai mai testato davvero un ripristino), una compromissione o un disco guasto possono chiudere l'attività, non solo rovinare la giornata.
Stai conservando più dati dei clienti del necessario
Ogni campo in più che conservi è una responsabilità che ti porti dietro. Salvare i dati completi delle carte, mantenere anni di dati personali senza una policy di conservazione o registrare dettagli sensibili nei log trasforma una violazione da "imbarazzante" a un problema PCI-DSS e GDPR con peso economico e legale reale. I dati più sicuri sono quelli che non hai mai conservato.
Un controllo autonomo di 10 minuti
Prima di chiedere aiuto a qualcuno — noi compresi — esegui questo controllo da solo. Non costa nulla e ti dice molto:
- Conferma la versione esatta di PrestaShop e verifica se è ancora supportata. Se è una 1.6.x o una delle prime 1.7.x, hai già la risposta.
- Apri l'elenco degli aggiornamenti dei moduli nel pannello di amministrazione e conta gli aggiornamenti in sospeso. Prendi nota dei moduli di fornitori che sono spariti.
- Elenca i dipendenti admin. Guarda la tabella
ps_employeeo la pagina Team e verifica che ogni account con accesso al back office sia uno che riconosci. - Confronta i file del core con una copia pulita della stessa versione di PrestaShop. Qualsiasi modifica in
/classes,/controllerso nella root che non hai fatto tu merita attenzione. - Ordina la webroot per data di modifica. I file modificati di recente che non riesci a spiegare sono il modo più rapido per individuare una backdoor.
- Conferma che i backup esistano fuori dal server e che il ripristino funzioni davvero. Un backup che non hai mai testato è una speranza, non un backup.
Se tutti e sei i controlli risultano puliti, è davvero rassicurante — e potresti non dover spendere nemmeno un centesimo. Se anche solo uno ti mette a disagio, quel disagio è il segnale utile.
Se hai accesso alla shell o al database, tre comandi in sola lettura
Questi comandi confermano alcuni dei controlli sopra e sono rigorosamente in sola lettura: elencano e confrontano, non modificano nulla. Adatta il prefisso della tabella ps_ al tuo.
# 1. List every account with back-office access — look for anyone you don't recognise
SELECT id_employee, email, lastname, firstname, active, last_connection_date
FROM ps_employee
ORDER BY last_connection_date DESC;
# 2. Spot recently-modified PHP files in the webroot (a common backdoor tell)
find /path/to/your/shop -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td %p\n' \
| sort
# 3. Confirm your stored PrestaShop version, then compare it to the supported list
mysql -e "SELECT value FROM ps_configuration WHERE name='PS_VERSION_DB';"La query sui dipendenti è il modo più rapido per individuare un account admin non autorizzato; un'email sconosciuta o una riga active=1 che nessuno ha creato è un segnale serio. Il comando find mostra i file toccati negli ultimi 30 giorni: confronta ciascuno con il lavoro che hai effettivamente svolto. Nessuno di questi elementi dimostra da solo una compromissione, ma qualsiasi cosa inspiegabile qui è esattamente quel "segnale utile" che merita di essere approfondito.
La parte onesta: diagnostica prima di acquistare
Ecco il passaggio che la maggior parte delle proposte di sicurezza salta. La risposta giusta a questi segnali non è quasi mai "compra un prodotto". È "scopri cosa non va davvero". A volte la soluzione riguarda configurazione o hosting: un server configurato male, un WAF mancante, un origin esposto. In quel caso il passo rilevante è un audit dell'hosting, non un modulo. A volte serve un hardening: chiudere il percorso admin, aggiungere limitazione dei tentativi e 2FA. È qui che un modulo a codice aperto come Security Revolution trova il suo posto — ma solo dopo aver confermato che quello è il problema. E a volte serve una bonifica perché qualcosa è già entrato, che è un lavoro mirato a sé.
È esattamente per questo che vale la pena iniziare con un audit di sicurezza: mappa la tua esposizione reale e ti dice su quale di queste tre strade ti trovi davvero, così non spendi soldi per risolvere un problema che non hai. Lo avvii inserendo l'URL del tuo negozio nella pagina dell'audit di sicurezza; viene eseguito un controllo di preparazione in sola lettura sull'URL e solo dopo l'audit viene ordinato.
Se consegnare accessi ti rende nervoso — ed è giusto che sia così — quell'istinto è corretto, e abbiamo costruito il processo intorno a questo principio. L'audit viene svolto in sola lettura: guardiamo, non scriviamo, e non tocchiamo mai il database dei tuoi clienti. Abbiamo documentato esattamente cosa significa, e a cosa accediamo o non accediamo, nella nostra guida alla preparazione dell'audit del negozio, che vale la pena leggere prima di ordinare, così sai con precisione cosa stai accettando. Sicurezza e prestazioni spesso vanno insieme, quindi se stai già mappando lo stato di salute del tuo negozio vale la pena dare un'occhiata anche ai più ampi servizi specialistici e all'audit delle prestazioni.
Esegui oggi il controllo da dieci minuti. Se è pulito, goditi la tranquillità: te la sei guadagnata gratis. Se non lo è, ora sai abbastanza per porre la domanda giusta, che vale molto più di qualsiasi singolo prodotto.
Domande frequenti
Un audit di sicurezza rimuove un'infezione o si limita a trovarla?
Un audit diagnostica: mappa la tua esposizione e ti dice se qualcosa è già entrato. La bonifica è un lavoro separato e mirato, perché rimuovere una backdoor in modo sicuro significa trovare ogni punto di ingresso, non solo quello che hai notato, e poi chiudere la falla che l'ha lasciata entrare perché non ritorni. L'audit è ciò che ti dice se hai bisogno di una bonifica e quanto deve andare in profondità. Tratta con cautela qualsiasi promessa del tipo "scansioniamo e risolviamo tutto in un solo passaggio"; una backdoor silenziosa e persistente raramente se ne va in modo così pulito.
Uso un PrestaShop 8 aggiornato con tutto al passo. Ho comunque bisogno di un audit?
Forse no, ed è una buona posizione in cui trovarsi. Un core attuale con moduli aggiornati elimina i rischi più grandi e più scansionati. Le domande residue a cui un audit risponde sono quelle che gli aggiornamenti non coprono: il tuo IP origin trapela dietro la CDN, il percorso admin è esposto a tentativi di forza bruta, hai un monitoraggio dell'integrità dei file e un backup esterno testato, e stai conservando più dati dei clienti di quanto dovresti? Se anche il controllo autonomo di dieci minuti è pulito su questi aspetti, sei davvero in una buona situazione.
Avrete bisogno della mia password admin o di una copia del mio database?
No. Un audit di sicurezza parte solo dall'URL del tuo negozio e lavora in gran parte dall'esterno verso l'interno. Quando un controllo richiede di guardare dentro il back office, basta un account dipendente in sola lettura, e non chiediamo né prendiamo mai una copia dei dati dei tuoi clienti o dei tuoi ordini. Il modello di accesso completo è nella guida alla preparazione dell'audit del negozio: leggila prima di ordinare, così sai esattamente cosa comporta.
Come distinguo una vera compromissione da un falso allarme nel controllo autonomo?
Spesso non puoi farlo da solo, e questo è il limite onesto di un controllo autonomo: serve a far emergere segnali, non a confermarli. Un file modificato di recente potrebbe essere un aggiornamento legittimo; un dipendente sconosciuto potrebbe essere un ex collaboratore. Il compito del controllo autonomo è dirti se devi guardare più a fondo. Quando emerge qualcosa di inspiegabile e non riesci a ricondurlo a un'attività nota, è il momento in cui una revisione esterna si ripaga da sola, perché confermare "questo va bene" ha lo stesso valore di confermare "questo non va bene".
Ogni quanto dovrei eseguire il controllo autonomo?
La versione da dieci minuti è abbastanza semplice da eseguire ogni trimestre e dopo qualsiasi cambiamento importante: un upgrade di PrestaShop, un nuovo modulo di pagamento, un cambio di tema o un avvicendamento del personale che ha interessato gli accessi admin. I due controlli che vale la pena automatizzare, invece di ripetere a mano, sono il monitoraggio dell'integrità dei file e i backup esterni testati; una volta che questi girano in modo continuo, per il resto si tratta soprattutto di confermare che nulla sia cambiato fuori controllo.
Commenti
Ancora nessun commento. Sii il primo!
Sii il primo a fare una domanda o a condividere un feedback utile.
Lascia un commento
Condividi una domanda, un dettaglio di installazione o un feedback utile per un altro lettore.