Rafforzamento della sicurezza di PrestaShop: la checklist completa

Un negozio PrestaShop è un bersaglio interessante per un motivo semplice: si trova all'incrocio tra denaro e dati personali, con flussi di pagamento con carta, nomi e indirizzi dei clienti, cronologia degli ordini e un pannello di amministrazione raggiungibile da qualsiasi punto di internet. La maggior parte degli attacchi che lo colpiscono non è particolarmente sofisticata: sono automatizzati, indiscriminati e cercano l'unica casella che hai dimenticato di spuntare. Questa pagina è proprio quell'elenco di caselle. È la checklist principale per rafforzare la sicurezza di un negozio PrestaShop, ordinata in modo da affrontare prima gli interventi con il massimo ritorno e il minimo sforzo, rimandando ogni tema più approfondito alla guida che lo tratta nel dettaglio.

Revisionato a giugno 2026. Questi controlli si applicano a PrestaShop 1.7, 8 e 9 (il back office di PS9 usa Symfony 6.4); manteniamo questa checklist aggiornata man mano che cambiano gli avvisi di sicurezza e le date di supporto PHP.

Usala come una checklist, non come un saggio. Procedi dall'alto verso il basso: gli elementi del Livello 1 chiudono le porte che gli scanner automatici provano a forzare ogni giorno, e puoi completarne la maggior parte dal back office o dal pannello di hosting in un pomeriggio. Se vuoi partire dagli stessi concetti spiegati in modo semplice e senza gergo tecnico, leggi prima la nostra guida in linguaggio chiaro per titolari di negozi e poi torna qui per il controllo completo.

Come usare questa checklist

Ogni voce qui sotto è un controllo con un responsabile chiaro e un beneficio concreto. Quando un controllo è abbastanza ampio da meritare una guida dedicata — configurazione della 2FA, regole .htaccess, SSL, blocco dei bot — questa pagina ti dà il "cosa e perché" in un paragrafo, poi rimanda alla guida passo passo. Questa struttura a hub e guide collegate è voluta: qui hai la mappa completa senza dover rileggere per la quinta volta una spiegazione su reCAPTCHA, e segui il link quando sei pronto a configurare davvero qualcosa.

Prima di iniziare, una distinzione utile: la maggior parte di questi controlli serve a ridurre la superficie di attacco (meno porte aperte), mentre alcuni servono a rilevare e recuperare quando qualcosa riesce a passare (allarmi e uscite di sicurezza). Un negozio sicuro ha bisogno di entrambe le cose. Un negozio con una password admin di 16 caratteri ma senza backup è a un aggiornamento di modulo andato male da una settimana molto complicata.

Livello 1 — Elementi essenziali (falli questa settimana)

1. Rinomina la cartella admin

PrestaShop installa già la cartella di amministrazione con un suffisso casuale (qualcosa come admin8f3k2) proprio per questo motivo — ma molti negozi aggiornati da versioni più vecchie usano ancora un /admin o /adminXXXX facile da indovinare, che gli scanner provano per primi. Rinomina la cartella via FTP/SFTP o dal file manager del tuo hosting con un nome che nessuno possa prevedere (evita parole ovvie come backoffice, manage o panel — vengono scansionate anche quelle). PrestaShop rileverà il cambio di nome al login successivo; dopo, aggiorna il segnalibro e comunica al team il nuovo URL. Perché conta? La principale fonte di traffico brute-force contro l'admin sono i bot che martellano URL di accesso prevedibili. Sposta la porta e la maggior parte di loro non la troverà mai.

2. Password admin forti e uniche — e pulizia degli account

Ogni account del back office dovrebbe usare una password lunga e unica (16+ caratteri), generata e salvata in un gestore di password, mai riutilizzata altrove. Altrettanto importante: apri Parametri avanzati → Team → Dipendenti ed elimina ogni account che non ha più bisogno di accesso. Il login admin dormiente di un ex freelance è pura superficie di attacco senza alcun beneficio. Già che ci sei, verifica che nessuno abbia creato di nascosto un account che non riconosci.

3. Forza HTTPS ovunque

Far passare pagamento e accesso su semplice HTTP nel 2026 non è un rischio da accettare, è un difetto da correggere. HTTPS protegge credenziali, dati delle carte e informazioni personali durante il transito, e PrestaShop include un'opzione integrata per imporlo in Parametri negozio → Generale → Abilita SSL più Abilita SSL su tutte le pagine. Se non hai ancora installato un certificato e imposto HTTPS su tutto il sito, segui la nostra guida alla configurazione di SSL e HTTPS: copre l'installazione del certificato, le due opzioni di PrestaShop e la correzione degli avvisi di contenuto misto che spesso creano problemi.

4. Mantieni aggiornati PrestaShop e PHP

La stragrande maggioranza dei negozi PrestaShop compromessi usava una versione con una vulnerabilità pubblicamente nota e già corretta. Resta su una release supportata, iscriviti agli avvisi di sicurezza di PrestaShop e non usare mai una build PHP fuori ciclo di vita (7.4 e 8.0 hanno entrambe superato le date di supporto di sicurezza). Prima di qualsiasi aggiornamento del core: fai un backup completo, testa su una copia di staging e verifica che i moduli siano compatibili. Perché conta? Applicare patch non è affascinante, ma "eravamo una versione indietro" è la frase più comune nelle analisi successive a una violazione.

5. Riduci ciò che pagine di errore e header rivelano

Assicurati che la modalità debug sia disattivata in produzione: verifica che _PS_MODE_DEV_ sia false in config/defines.inc.php e controlla che Parametri avanzati → Prestazioni → Modalità debug sia disabilitata, così uno stack trace non consegna mai a un aggressore i percorsi dei file, il prefisso delle tabelle o le versioni delle librerie. Una pagina di debug esposta è una mappa gratuita della tua installazione.

Livello 2 — Controllo degli accessi

6. Attiva l'autenticazione a due fattori per il back office

La 2FA significa che una password admin rubata, da sola, non basta per accedere: all'aggressore serve anche il codice sul tuo telefono. Questo blocca in un colpo solo credential stuffing e phishing, ed è il controllo di accesso con il valore più alto che puoi aggiungere. La configurazione completa, incluse policy delle password e rafforzamento delle sessioni, ha una guida dedicata: autenticazione a due fattori, policy delle password e sicurezza admin per PrestaShop.

7. Limita i tentativi e blocca gli accessi falliti

Gli strumenti brute-force provano migliaia di password. Metti un limite: attiva un blocco temporaneo dopo una manciata di tentativi falliti (una policy comune è un blocco di 15 minuti dopo cinque errori, e un blocco lungo o ban dell'IP dopo venti). PrestaShop non limita in modo aggressivo i login admin da solo, quindi di solito questo controllo viene gestito a livello di WAF/perimetro o con un modulo di sicurezza.

8. Limita l'accesso admin per IP

Se il tuo team accede da indirizzi fissi (ufficio, casa, uscita di una VPN), limita la cartella admin a quegli IP con una regola .htaccess (Require ip ... su Apache) o con il firewall. Questo singolo controllo elimina direttamente gran parte del traffico brute-force e di credential stuffing, perché le richieste dell'aggressore non raggiungono nemmeno il modulo di login. Le regole esatte sono nella nostra guida alle regole .htaccess per sicurezza e prestazioni.

9. Restringi i permessi dei dipendenti

Il sistema di profili di PrestaShop in Parametri avanzati → Team → Permessi è granulare: usalo. Un redattore di contenuti non ha bisogno di gestire i moduli; un addetto al servizio clienti non ha bisogno delle impostazioni server o di SQL Manager. Dai a ogni profilo il minimo necessario, poi riesamina periodicamente l'elenco dei dipendenti e rimuovi chi non lavora più con te. Il principio del minimo privilegio significa che un singolo account del personale compromesso non può mettere a rischio l'intero negozio.

Livello 3 — Rafforzamento di server e file

Su nginx, l'equivalente è una regola di deny per le cartelle sensibili dell'applicazione e per i PHP caricati. I percorsi variano in base alla struttura dell'hosting, quindi testa prima con nginx -t e con una richiesta su staging.

location ~* ^/(app|var|vendor|config|classes|controllers|override)/ {
    deny all;
}

location ~* /(img|upload)/.*\.php$ {
    deny all;
}

Regole server e header di sicurezza dovrebbero essere verificati insieme dopo il rafforzamento.

10. Imposta i permessi corretti dei file

Le cartelle dovrebbero essere 755, i file 644. Nulla in un'installazione PrestaShop dovrebbe mai essere 777 (scrivibile da tutti): se un tutorial ti dice di usare chmod 777 per "farlo funzionare", il problema è quel tutorial. I file scrivibili da tutti sono esattamente ciò che serve a un exploit di caricamento file per depositare una backdoor.

11. Blocca l'accesso web diretto alle cartelle sensibili

Diverse cartelle di PrestaShop non dovrebbero mai essere raggiungibili da un browser: /app/, /cache/, /config/, /var/, /vendor/, /translations/, /mails/ e simili. Il .htaccess fornito con PrestaShop ne copre alcune, ma verificale e aggiungi ciò che manca (e conferma che Options -Indexes sia impostato, così il listing delle directory è disattivato; altrimenti rivela l'elenco esatto dei tuoi moduli a chiunque sia curioso). Il set completo di regole — cartelle sensibili, listing, dotfile — è nella guida alle regole .htaccess per sicurezza e prestazioni.

12. Aggiungi header di sicurezza HTTP

Gli header di sicurezza indicano al browser di attivare protezioni aggiuntive. Il set ad alto valore per un negozio PrestaShop: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN (anti-clickjacking), Strict-Transport-Security (aggiungilo solo quando HTTPS è solido — vedi punto 3), Referrer-Policy: strict-origin-when-cross-origin e una Content-Security-Policy distribuita prima in modalità report-only, così non rompi gli script del tuo tema. In particolare, la CSP è la tua difesa più forte contro un card skimmer che inietta uno script malevolo nella procedura di pagamento: è esattamente ciò che succede nell'attacco descritto nella nostra guida sull'anatomia di un attacco in stile Magecart su PrestaShop.

13. Metti un WAF davanti al negozio

Un web application firewall filtra il traffico malevolo prima che tocchi PrestaShop. Il piano gratuito di Cloudflare blocca molti schemi comuni e aggiunge protezione DDoS; Cloudflare Pro e ModSecurity (con OWASP Core Rule Set) vanno oltre. Un WAF è anche la tua prima linea contro pressioni volumetriche e generate da crawler, incluso il flood ?q= della ricerca a faccette che può trasformare silenziosamente gli URL dei filtri di PrestaShop in un denial-of-service autoinflitto, che analizziamo e contrastiamo con regole Cloudflare in sopravvivere al flood ?q=.

Livello 4 — Igiene di moduli e API

14. Fai un audit severo dei moduli installati

Ogni modulo è codice che gira dentro il tuo negozio, e ogni modulo inutilizzato è un rischio senza ritorno. Tre regole: rimuovi tutto ciò che non usi attivamente (disabilitarlo non basta: i file PHP sono ancora raggiungibili); non usare mai moduli nulled (piratati), che spesso includono backdoor; e mantieni tutto aggiornato, controllando il sito dello sviluppatore per eventuali avvisi. Dopo il core non aggiornato, i moduli di terze parti obsoleti sono il vettore di compromissione più comune su PrestaShop.

15. Metti in sicurezza o disattiva la Webservice API

Se usi la Webservice API di PrestaShop (Parametri avanzati → Webservice), assegna a ogni chiave solo le risorse minime necessarie invece dell'accesso completo, elimina le chiavi inutilizzate, richiedi HTTPS e limita per IP dove puoi. Se non la usi, imposta Abilita il webservice di PrestaShop su No. Una chiave API con troppi permessi è un'esportazione completa dei dati pronta a succedere.

16. Rimuovi dati predefiniti e di esempio

Prodotti demo rimasti, categorie di esempio e pagine CMS predefinite non servono a nulla e suggeriscono età e struttura della tua installazione. Eliminali appena il negozio diventa reale.

Livello 5 — Abusi sul front end e controllo dei bot

17. Ferma lo spam nei moduli con reCAPTCHA

Moduli di contatto, registrazione account, recensioni e iscrizioni alla newsletter sono le porte da cui i bot entrano per riempire il negozio di spazzatura e cercare punti deboli. reCAPTCHA ferma il rumore automatizzato senza bloccare i clienti reali: configurato e regolato nel modo giusto per PrestaShop nella nostra guida a reCAPTCHA per PrestaShop.

18. Blocca bot dannosi e visitatori abusivi

Oltre al CAPTCHA, ti conviene filtrare il traffico che non ha alcun motivo valido per arrivare al tuo negozio: scraper, scanner di vulnerabilità e client che martellano endpoint. L'applicazione reale contro bot ostili va gestita da un WAF, da regole a livello server o da un modulo di sicurezza dedicato, non dalle impostazioni core di PrestaShop; Parametri negozio → Traffico & SEO aiuta solo con robots.txt e indicazioni per i crawler, che i bot ben educati rispettano ma gli scanner ignorano. Anche la geolocalizzazione può limitare interi Paesi, ma non è un controllo contro gli scanner. Gli strumenti più approfonditi sono in controllo visitatori: bloccare bot dannosi e traffico indesiderato. Per gestire recidivi specifici per IP — il cliente che continua a fare ordini fraudolenti, l'indirizzo che continua a sondare — vedi informazioni extra cliente e ban IP.

19. Proteggi con password ciò che non è pronto per il pubblico

Contenuti di staging, pagine B2B, una collezione non ancora pubblicata: tutto ciò che è online ma non dovrebbe ancora essere indicizzato o navigato dovrebbe stare dietro una password, invece di affidarsi a un URL oscuro. Gli approcci per PrestaShop sono in protezione con password per PrestaShop.

Livello 6 — Monitoraggio, risposta e ripristino

20. Monitoraggio dell'integrità dei file

Il modo più rapido per intercettare una compromissione è accorgersi nel momento esatto in cui cambia un file che non dovrebbe cambiare. Il monitoraggio dell'integrità dei file (FIM) crea impronte dei file di PrestaShop e dei moduli e ti avvisa quando uno viene modificato in modo inatteso: esattamente ciò che accade nell'istante in cui un aggressore inietta codice in un controller o in un template di pagamento. È il sistema di allerta precoce che trasforma una violazione silenziosa in una correzione nello stesso giorno.

21. Controlla i log di accesso

Rivedi i log di accesso del server cercando i segnali: raffiche di richieste da un singolo IP, hit ripetuti sul login admin, richieste per file inesistenti (sondaggio di vulnerabilità) e POST inattesi. Se il tuo hosting offre fail2ban, puntalo ai log di PrestaShop così i recidivi vengono bannati automaticamente. Sapere com'è la normalità è ciò che ti permette di individuare l'anomalia.

22. Monitoraggio di uptime e certificati

Un monitor gratuito come UptimeRobot che controlla downtime, scadenza SSL e picchi improvvisi nei tempi di risposta fa un doppio lavoro: rileva le interruzioni e segnala il consumo anomalo di risorse dovuto, per esempio, a un payload di cryptomining o a un flood di traffico prima che se ne accorgano i clienti.

23. Backup automatici, testati e fuori sede

Esegui ogni giorno il backup di file e database, conserva copie in almeno due posti (server più cloud esterno) e — questa è la parte che tutti saltano — testa davvero un ripristino ogni trimestre. Un backup che non hai mai ripristinato è una speranza, non un piano. Cifra con GPG i backup del database conservati fuori sede (contengono dati dei clienti). Mantieni qualcosa come 30 giorni di backup giornalieri e qualche mese di settimanali; lo spazio costa poco e un punto di ripristino pulito è ciò che separa te dal dover ricominciare da capo.

24. Scrivi il piano di risposta agli incidenti prima di averne bisogno

Quando un negozio viene compromesso, il momento peggiore per capire il passo successivo sono le 2 del mattino. Documentalo in anticipo: chi chiamare (hosting, processore di pagamento, specialista di sicurezza), come entrare in modalità manutenzione senza perdere ordini in corso, dove si trova l'ultimo backup pulito, come ripristinarlo e cosa verificare dopo. Se il peggio è già successo, la nostra guida alla risposta a una violazione dei dati accompagna l'intera sequenza passo dopo passo, inclusi gli obblighi di notifica GDPR.

Il caso speciale: un negozio che non puoi ancora aggiornare

La checklist sopra presuppone che tu possa applicare patch. Molti negozi reali non possono: un tema pesantemente personalizzato, un modulo critico senza versione compatibile, una migrazione di piattaforma prevista tra sei mesi. Questo non significa che tu sia indifeso. Patch virtuali, regole WAF al perimetro e rafforzamenti mirati possono schermare una vulnerabilità nota senza toccare il core, dandoti tempo per aggiornare correttamente. Il playbook completo per i negozi bloccati su una vecchia versione è rafforzamento avanzato di PrestaShop per negozi che non puoi ancora aggiornare.

Dove entrano in gioco i moduli — e dove no

La maggior parte di questa checklist non costa nulla se non attenzione: impostazioni che hai già nel back office, opzioni del pannello hosting, un'ora con il tuo .htaccess. Preferiamo che tu faccia prima queste cose, invece di comprare qualcosa. Un modulo merita il suo posto quando gestisce attività noiose o impossibili da fare a mano: soprattutto 2FA e rafforzamento del login, e monitoraggio continuo dell'integrità dei file che controlla ogni modifica al posto tuo, invece di costringerti a leggere i log a occhio. I nostri moduli di sicurezza su mypresta.rocks coprono questi livelli, configurati dal back office senza modifiche al core, così un aggiornamento non li annulla. Perché conta? Paghi per automatizzare i controlli che una persona non può seguire manualmente in modo costante, non per sostituire l'igiene gratuita che fa la maggior parte del lavoro.

Il riepilogo onesto

La sicurezza su PrestaShop non è un progetto che si conclude; è uno standard da mantenere. La buona notizia è che gli attacchi contro il tuo negozio sono per lo più stupidi e automatizzati, quindi i controlli basilari e poco appariscenti — patch, rinomina dell'admin, HTTPS forzato, password forti, 2FA, backup che hai davvero testato — fermano la stragrande maggioranza dei tentativi. Scendi lungo questa lista, apri le guide più approfondite quando arrivi a ciascun controllo e inserisci in calendario un promemoria trimestrale ricorrente per rifarla. I negozi che subiscono una violazione non sono quasi mai quelli che hanno fatto le cose noiose; sono quelli che avevano intenzione di farle.

Controllo rapido: elenca tutti gli account del back office con una query

Il punto 2 ti chiede di ripulire l'elenco dei dipendenti e verificare che nessuno abbia creato di nascosto un account che non riconosci. Il back office te lo mostra in Parametri avanzati → Team → Dipendenti, ma una query SQL in sola lettura è più rapida da scorrere e più difficile da occultare per un'interfaccia admin manomessa. Eseguila sul tuo database (adatta il prefisso ps_ al tuo): legge soltanto, non modifica nulla:

-- Read-only: every back-office account, newest first.
-- Flag SuperAdmins (id_profile = 1) you don't recognise, and any
-- account whose date_add is recent but that nobody on your team created.
SELECT id_employee, email, id_profile, active, date_add, last_connection_date
FROM ps_employee
ORDER BY date_add DESC;

Due righe meritano un secondo controllo: qualsiasi id_profile = 1 (SuperAdmin) che non ti aspettavi, e qualsiasi account il cui date_add cada in un periodo in cui non stavi inserendo nuovo personale. Un SuperAdmin malevolo creato durante una compromissione è una delle prime cose che un aggressore lascia per mantenere un accesso di ritorno, e sopravvive a una pulizia malware se ti limiti a ripulire i file. Disabilitalo dal back office invece di eliminarlo, se prima vuoi conservarlo come prova.

Domande frequenti

Sono un piccolo negozio senza sviluppatore. Quanto di tutto questo posso fare davvero da solo?

Gran parte del Livello 1 e del Livello 2 — rinominare la cartella admin, usare password forti, forzare HTTPS, attivare la 2FA, ripulire gli account, restringere i permessi — sono attività da back office o pannello hosting che non richiedono codice. Gli interventi a livello server (permessi dei file, .htaccess, header) sono quelli per cui è ragionevole chiedere aiuto al tuo hosting o a uno sviluppatore. Inizia dalla versione in linguaggio semplice nella nostra guida per titolari di negozi e procedi da lì.

Mi serve un modulo di sicurezza, o il rafforzamento gratuito basta?

Il rafforzamento gratuito fa la maggior parte del lavoro e dovresti farlo comunque per primo. Un modulo merita il suo posto solo per due attività noiose o impossibili da gestire a mano: 2FA più rafforzamento del login, e monitoraggio continuo dell'integrità dei file che controlla ogni modifica al posto tuo invece di costringerti a leggere i log a occhio. Se paghi, paghi per automatizzare quelle attività, non per sostituire le basi gratuite.

Il piano gratuito di Cloudflare basta come WAF?

Per un negozio tipico blocca molte scansioni comuni e aggiunge protezione DDoS, quindi vale la pena attivarlo. Ma il piano Free non può fare matching su query string o user-agent nelle regole di limitazione del traffico, e questo conta se sei sotto attacco mirato: per esempio, limitare un flood ?q= della ricerca a faccette richiede Pro. Spieghiamo esattamente dove il piano Free si ferma in rafforzamento avanzato per negozi che non puoi ancora aggiornare.

Ogni quanto dovrei eseguire questa checklist?

Inserisci in calendario un promemoria trimestrale ricorrente: venti minuti per confermare che PrestaShop e moduli siano aggiornati, la 2FA sia attiva per tutti, gli account degli ex dipendenti siano spariti e un backup si ripristini davvero. La sicurezza su PrestaShop non è un progetto che si conclude; è uno standard da mantenere.

Il mio negozio usa una versione che non posso aggiornare adesso. Sono semplicemente esposto?

No, ma passi dall'applicare patch al patching virtuale: regole WAF al perimetro, blocco dell'origine così gli aggressori non possono aggirarlo, e correzioni mirate per le vulnerabilità specifiche indicate da log e avvisi. Il playbook completo per i negozi bloccati su una vecchia versione è rafforzamento avanzato di PrestaShop per negozi che non puoi ancora aggiornare.

Continua a leggere

• Mettere in sicurezza il tuo negozio PrestaShop: una guida in linguaggio chiaro per titolari di negozi — gli stessi concetti senza gergo, per titolari non tecnici.
• Anatomia di un attacco in stile Magecart a un negozio PrestaShop 1.7.x — da cosa proteggono davvero questi controlli, visti dall'interno.
• Risposta a una violazione dei dati: cosa fare se il tuo negozio viene hackerato — il playbook calmo e passo passo per le prime ore.