Proteggere il Tuo Negozio PrestaShop: Una Guida Pratica per i Proprietari

Gestire un negozio online significa maneggiare denaro reale e dati reali dei clienti. Questo ti rende un bersaglio — non perché tu sia speciale, ma perché bot automatizzati scandagliano continuamente ogni installazione WordPress, Magento e PrestaShop su internet alla ricerca di vulnerabilità note. La buona notizia: la maggior parte degli attacchi riesce a causa di errori basilari, e gli errori basilari si possono correggere. Questa guida copre ciò che conta davvero, nell'ordine in cui conta davvero.

SSL: ce l'hai, ma funziona correttamente?

Oggi ogni negozio ha un certificato SSL. La maggior parte lo ha configurato male. Il lucchetto nel browser significa solo che la pagina stessa è stata caricata in HTTPS — non che il tuo negozio sia completamente cifrato. Il problema nascosto è il contenuto misto: immagini, script o fogli di stile che si caricano in HTTP semplice su una pagina HTTPS. I browser li bloccano silenziosamente, rompendo funzionalità senza messaggi di errore evidenti.

Apri Chrome DevTools sulla tua homepage, vai alla Console e cerca avvisi "Mixed Content". Correggili aggiornando gli URL http:// hardcoded nel tuo tema, nei moduli o nelle impostazioni del database. In PrestaShop, controlla in Parametri del negozio → Generale che sia il dominio del negozio che il dominio SSL puntino al tuo URL HTTPS.

Verifica anche che il redirect da HTTP a HTTPS funzioni a livello server, non solo all'interno di PrestaShop. Se qualcuno visita http://yourstore.com, deve ricevere un redirect 301 a https://yourstore.com prima ancora che PrestaShop si carichi. Controlla il tuo .htaccess — la regola di redirect deve precedere le regole di rewrite di PrestaShop, non essere sepolta dentro di esse.

Il tuo URL di amministrazione è di dominio pubblico

Ogni installazione predefinita di PrestaShop posiziona il pannello di amministrazione sotto /admin seguito da un suffisso casuale generato durante l'installazione. Quel suffisso non è una misura di sicurezza — è solo un ostacolo. I bot enumerano i pattern comuni. Il tuo URL di amministrazione non è così nascosto come pensi.

Rinomina la directory admin con qualcosa che non contenga la parola "admin". Scegli qualcosa di privo di significato — evita del tutto le parole del dizionario. Non fermerà un attaccante determinato con accesso ai tuoi file, ma elimina istantaneamente la scansione automatizzata di massa.

Se il tuo hosting supporta il whitelisting degli IP tramite .htaccess, usalo. Aggiungi una direttiva Require ip nell'.htaccess della tua cartella admin per permettere solo gli indirizzi IP del tuo ufficio e di casa. Sì, è scomodo quando viaggi. Sì, ne vale la pena.

Account dipendenti: una persona, un account, nessuna eccezione

Gli account admin condivisi sono una delle cause più comuni di incidenti di sicurezza — e le più difficili da analizzare in seguito. Quando tutti i dipendenti accedono come "admin", non hai nessuna traccia di audit. Non puoi sapere chi ha eliminato un prodotto, chi ha cambiato un prezzo, o chi ha esportato la lista clienti alle 2 di notte.

Crea account individuali per ogni persona che necessita di accesso al back-office. Usa correttamente i profili di permesso di PrestaShop: un addetto al servizio clienti non ha bisogno di accedere alle impostazioni di pagamento. Un operatore di magazzino non ha bisogno di accedere alla gestione dipendenti. Il principio del minimo privilegio non è burocrazia — limita i danni quando un account viene compromesso.

Controlla la tua lista dipendenti ogni trimestre. Rimuovi gli account delle persone che non lavorano più per te. Gli ex dipendenti con credenziali attive sono un vero vettore di rischio, e uno che controlli completamente tu.

Sicurezza dei moduli: la superficie di attacco che non stai monitorando

I moduli sono il punto di ingresso più comune per le compromissioni dei negozi PrestaShop. Un modulo vulnerabile — anche uno che non usi più attivamente — può essere sfruttato se è installato e abilitato. Agli attaccanti non importa che tu non abbia toccato quel modulo di pagamento da due anni. Se è lì ed è vulnerabile, è una porta aperta.

Installa solo moduli da fonti di cui ti fidi. Il marketplace PrestaShop Addons verifica i contributi, ma i siti di terze parti casuali e i repo GitHub a caso non lo fanno. I moduli nulled — moduli a pagamento distribuiti illegalmente e gratuitamente — contengono quasi sempre backdoor. La logica è semplice: perché qualcuno distribuirebbe gratuitamente software a pagamento? Perché ci ha aggiunto qualcosa.

Rimuovi i moduli che non usi. Non solo disabilitarli — disinstallarli e cancellare i file. Ogni modulo installato aggiunge codice che si carica a ogni richiesta, aumentando sia la superficie di attacco sia il tempo di caricamento della pagina. Fai un audit dei moduli: se non lo usi da sei mesi e non hai in programma di farlo, va eliminato.

Aggiorna i tuoi moduli regolarmente. La maggior parte delle vulnerabilità nei moduli viene corretta rapidamente una volta scoperta — ma la patch aiuta solo se la installi. Il nostro modulo Security Revolution include il monitoraggio dell'integrità dei file che segnala modifiche inattese ai file dei tuoi moduli, e il nostro modulo Total Defender aggiunge livelli di protezione attiva tra cui il blocco dei bot e il logging delle attività sospette.

Backup del database: l'unica cosa che garantisce il ripristino

I backup non sono una misura di sicurezza — sono una misura di ripristino. La distinzione è importante perché cambia il modo in cui li concepisci. Nessuna strategia di backup previene un attacco. I buoni backup significano che un attacco non mette fine alla tua attività.

Automatizza i tuoi backup. I backup manuali vengono saltati, rimandati e dimenticati. Configura un cron job che esporti il tuo database ogni notte e lo copi fuori dal server. "Fuori dal server" significa in un posto tale che una compromissione del tuo server web non comprometta anche i tuoi backup — un bucket di storage cloud separato, la tua macchina locale, ovunque che non sia la stessa macchina che potrebbe essere cancellata.

Testa i tuoi ripristini. Un backup che non hai mai ripristinato non è un backup — è un file con contenuto sconosciuto. Esegui un ripristino di test su un ambiente di staging almeno una volta al trimestre. Non vuoi che la prima volta che ripristini da un backup sia durante un incidente reale.

Mantieni più punti di ripristino. Backup giornalieri per gli ultimi 30 giorni, settimanali per gli ultimi sei mesi. Alcuni attacchi — in particolare la manipolazione del database — non vengono scoperti immediatamente. Devi poter ripristinare un punto precedente all'inizio della compromissione.

Password e autenticazione a due fattori

PrestaShop supporta l'autenticazione a due fattori nativamente dalla versione 1.7.6. Se non la stai usando per i tuoi account admin, attivala oggi. La configurazione richiede cinque minuti. Vai al tuo profilo nel back-office e abilita il 2FA usando un'app di autenticazione come Google Authenticator o Authy.

Richiedi il 2FA per tutti gli account admin, non solo il tuo. Un dipendente con una password debole e senza 2FA è l'anello più debole della tua catena di sicurezza.

Sulle password: usa un gestore di password e genera password lunghe e casuali per ogni account. "Lungo" significa almeno 20 caratteri per gli account admin. Non riutilizzare mai le password tra i servizi. La tua password admin di PrestaShop non deve comparire da nessun'altra parte — né nel tuo pannello di hosting, né nella tua email, né nel tuo account sul marketplace dei moduli.

Permessi dei file: le basi contano ancora

I permessi corretti per un'installazione PrestaShop sono 755 per le directory e 644 per i file. Se tu o il tuo provider di hosting avete mai impostato i permessi a 777 "per risolvere un problema", torna indietro e risolvilo correttamente. I file scrivibili da tutti significano che qualsiasi processo sul server — incluso il codice iniettato attraverso una vulnerabilità — può modificarli.

Controlla in particolare i permessi del tuo file config/settings.inc.php. Contiene le tue credenziali del database. Dovrebbe essere 444 o 640 — leggibile dal server web, non scrivibile da nessuno.

Se sei su hosting condiviso, il tuo profilo di rischio è più alto perché condividi un server con altri siti. Una compromissione di un altro sito sul tuo server può potenzialmente influenzare il tuo se i permessi sono troppo aperti. Questo è uno dei veri argomenti a favore del VPS rispetto all'hosting condiviso per i negozi che gestiscono un volume reale di transazioni.

Mantenere PrestaShop e PHP aggiornati

Le vecchie versioni di PHP non sono solo più lente — smettono di ricevere patch di sicurezza. PHP 7.4 ha raggiunto la fine del ciclo di vita nel novembre 2022. Se il tuo host la sta ancora eseguendo (e molti hosting condivisi lo fanno ancora), stai eseguendo vulnerabilità note e non patchate nell'ambiente di runtime del tuo server. Controlla la tua versione PHP nel back-office di PrestaShop sotto Parametri Avanzati → Informazioni.

PrestaShop rilascia patch di sicurezza nelle versioni minori. Usare la 8.1.0 quando la 8.1.7 è disponibile significa avere buchi di sicurezza noti aperti. Gli aggiornamenti di versione principale richiedono più attenzione, ma gli aggiornamenti di versione minore all'interno dello stesso ramo sono generalmente sicuri e dovrebbero essere applicati prontamente dopo un backup e un test di staging.

Rafforzamento del .htaccess

Il .htaccess predefinito di PrestaShop è un punto di partenza, non una configurazione di sicurezza completa. Aggiungi queste regole per bloccare l'accesso diretto alle directory che non dovrebbero mai essere pubblicamente accessibili:

• Bloccare l'accesso diretto a /config/ — contiene le credenziali del database e le chiavi di cifratura
• Bloccare l'accesso diretto a /var/ — contiene file di cache e log
• Bloccare l'accesso diretto a /vendor/ — contiene file di librerie di terze parti
• Bloccare l'accesso diretto a /src/ — contiene i file sorgente del core
• Bloccare l'esecuzione di file PHP dentro /upload/ — un comune bersaglio per upload di malware

Per la directory di upload in particolare, aggiungi un .htaccess dentro /upload/ che nega l'esecuzione di PHP. Se un attaccante carica una shell PHP attraverso una vulnerabilità di upload di file, questa regola gli impedisce di eseguirla.

GDPR e sicurezza dei cookie

La sicurezza dei cookie non riguarda solo la conformità — i cookie configurati male possono esporre token di sessione e dati di autenticazione. Assicurati che i tuoi cookie di sessione siano impostati con il flag Secure (trasmessi solo via HTTPS) e il flag HttpOnly (non accessibili a JavaScript). Se hai bisogno di una corretta implementazione del consenso ai cookie GDPR che non comprometta la funzionalità del tuo negozio, il nostro modulo Cookies Revolution lo gestisce correttamente.

Se vieni hackerato: cosa fare davvero

Prima di tutto: non farti prendere dal panico, ma agisci in fretta. Ogni ora di ritardo significa più danni potenziali.

Isola immediatamente. Porta il tuo negozio offline o mettilo in modalità manutenzione. Se il tuo host ha un'opzione "sospendi sito", usala. Devi fermare l'emorragia prima di diagnosticare la ferita.

Non cancellare nulla ancora. L'istinto sarà di fare pulizia, ma devi preservare le prove per capire cosa è successo. Fai un backup completo dello stato compromesso prima di iniziare a rimuovere file.

Controlla le date di modifica dei file. Esegui una ricerca dei file modificati negli ultimi 30 giorni. Confronta con la tua storia dei deployment. I file che sono cambiati senza un aggiornamento corrispondente sono indicatori di compromissione. Presta particolare attenzione ai file PHP in /upload/, /img/ e nelle directory dei moduli — posti dove le scritture di file sono attese e più facili da nascondere.

Ripristina da un backup pulito. Non cercare di rimuovere chirurgicamente il malware da un sito live — gli attaccanti sono bravi a nascondere backdoor e ne perderai qualcuna. Ripristina da un backup di cui sei certo che preceda la compromissione.

Cambia tutte le password. Password del database, credenziali FTP, pannello di hosting, account admin di PrestaShop, account email associati al dominio. Supponi che tutto fosse leggibile durante il periodo di compromissione.

Trova il punto di ingresso. Questo è importante per prevenire la recidiva. Punti di ingresso comuni: un modulo vulnerabile, credenziali di dipendenti compromesse, una password admin violata con brute force. Se non riesci a identificare come è successo, succederà di nuovo.

Notifica in modo appropriato. Se è stato effettuato l'accesso ai dati dei clienti — indirizzi email, cronologia degli ordini, qualsiasi dato di pagamento — hai probabilmente obblighi legali di notifica a seconda della tua giurisdizione. Il GDPR richiede la notifica entro 72 ore dal momento in cui si è a conoscenza di una violazione. Non rimandare.

La sicurezza non è una funzionalità che aggiungi una volta sola e poi dimentichi. È manutenzione, come mantenere aggiornati i contenuti del negozio o l'inventario accurato. Imposta un promemoria trimestrale per controllare gli account dei dipendenti, verificare gli aggiornamenti dei moduli e assicurarti che i tuoi backup si ripristinino davvero. Venti minuti ogni tre mesi sono molto meno costosi del recupero da una violazione.

Articoli Correlati

• Sicurezza dei pagamenti in PrestaShop: PCI Compliance, 3D Secure e prevenzione delle frodi
• Sicurezza PrestaShop: La checklist completa per il rafforzamento
• Risposta alle Violazioni dei Dati: Cosa Fare Se il Tuo Negozio Viene Hackerato