Mettere in sicurezza il tuo store PrestaShop: guida chiara per proprietari

Se gestisci uno store PrestaShop e la parola "sicurezza" ti fa chiudere un po' lo stomaco, questa guida è per te. Non devi essere uno sviluppatore. Devi capire abbastanza bene poche idee per prendere buone decisioni e sapere quali lavori puoi fare da solo dal back office e quali conviene passare a un developer. Questo è il senso della guida: una mappa in linguaggio chiaro della sicurezza di uno store PrestaShop, nell'ordine in cui le cose contano davvero, con ogni tema profondo linkato alla sua guida completa così questa pagina non diventa un muro da 6.000 parole che non finirai mai.

Prima di tutto, un cambio di prospettiva. Non vieni preso di mira perché il tuo store è importante. Vieni preso di mira perché un bot non sa e non gli interessa cosa sia il tuo store. Gli scanner automatici percorrono tutto internet cercando qualunque installazione WordPress, Magento o PrestaShop con una debolezza nota, come un ladro che cammina per strada provando ogni maniglia. Quasi ogni attacco riuscito che vediamo risale a una porta di base lasciata aperta: una versione vecchia, una password riusata, un modulo nulled, non un hacker geniale. È una buona notizia, perché le porte di base sono quelle che puoi chiudere anche tu.

Il modello mentale: livelli, non un pulsante magico

Non esiste una singola impostazione che "mette in sicurezza" uno store PrestaShop, e qualunque prodotto che lo prometta ti sta vendendo qualcosa. La sicurezza reale è fatta a livelli: ciascuno cattura ciò che il livello sopra ha mancato. Pensala come un negozio fisico: serratura alla porta, cassa svuotata la sera, assicurazione e telecamera. Nessuna singola cosa è la risposta; insieme significano che un errore non ti distrugge.

Per uno store PrestaShop i livelli sono più o meno questi, e aiuta sapere chi gestisce cosa:

Nota che "poter recuperare" è nella lista. Chi lavora nella sicurezza dice: non è se, è quando. Uno store che può essere ripristinato completamente da un backup pulito in un'ora è in una posizione completamente diversa da uno che non può, indipendentemente da quanto siano buone le difese. Sistema bene il layer di recovery e ogni altro errore diventa sopravvivibile.

Inizia qui: le cinque cose che fermano più attacchi

Se fai solo cinque cose, fai queste. Sono in ordine di ritorno sullo sforzo, e ognuna è qualcosa che un proprietario non tecnico può fare senza developer.

1. Aggiorna PrestaShop, PHP e i moduli

È noioso ed è l'abitudine più importante. Il software vecchio smette di ricevere patch di sicurezza, quindi buchi noti restano aperti. PrestaShop rilascia fix di sicurezza nelle minor version: usare 8.1.0 quando esiste 8.1.7 significa girare con vulnerabilità pubblicamente documentate che i bot sanno già trovare. Controlla la versione PHP in Parametri avanzati → Informazioni nel back office; se mostra una versione end-of-life come 7.4, chiedi all'host di spostarti avanti. Gli aggiornamenti minor nello stesso ramo (per esempio 8.1.x a 8.1.x) sono di solito sicuri dopo backup e test staging. I moduli contano altrettanto: un modulo vulnerabile è il punto di ingresso più comune.

Se sei bloccato su una vecchia versione PrestaShop che non puoi aggiornare in sicurezza ora, una situazione reale per molti store avviati, ci sono modi per chiudere i gap senza upgrade. Li trattiamo in hardening avanzato per store che non puoi ancora aggiornare.

2. Attiva l'autenticazione a due fattori per ogni admin

PrestaShop non offre 2FA universale nativo sulle installazioni 1.7/8; aggiungilo con un modulo affidabile o un layer esterno di identità/sicurezza. Significa che anche se qualcuno ruba la password, non può accedere senza il codice sul telefono. Il setup richiede circa cinque minuti con un'app come Google Authenticator o Authy. Attivalo per ogni account dipendente, non solo per il tuo: un dipendente con password debole e senza 2FA è l'anello più debole, e gli attaccanti puntano sempre all'anello più debole. Il walkthrough completo, più le policy password per il back office, è in 2FA, policy password e sicurezza admin per PrestaShop.

3. Assicurati che HTTPS funzioni davvero

Quasi ogni store ormai ha un certificato SSL, ma "lucchetto nel browser" non significa "completamente sicuro". Il lucchetto conferma solo che la pagina è caricata via HTTPS: non dice nulla su immagini o script che arrivano in chiaro via http:// (mixed content, che i browser bloccano silenziosamente, rompendo cose senza errore ovvio). Non garantisce nemmeno che chi digita l'indirizzo http:// venga reindirizzato alla versione sicura prima che PrestaShop carichi. Entrambe le cose meritano attenzione. Il passo-passo — dall'attivazione SSL in Parametri negozio → Generale alla correzione mixed content e redirect server-level — è in come configurare SSL e HTTPS su PrestaShop.

4. Una persona, un account, e least privilege

I login condivisi ("tutti entrano come admin") sono una delle cause più comuni di incidenti e le più difficili da investigare dopo, perché non hai audit trail. Non puoi sapere chi ha cambiato un prezzo, chi ha cancellato un prodotto o chi ha esportato la lista clienti alle 2 di notte. Crea un account individuale per ogni persona che ha bisogno del back office e usa i profili permessi di PrestaShop (in Parametri avanzati → Team) così ciascuno riceve solo ciò che serve al suo lavoro. Un customer service non ha bisogno delle impostazioni pagamento; un operatore magazzino non ha bisogno della gestione dipendenti. Non è burocrazia: limita il raggio dell'esplosione quando un account viene compromesso. Audita la lista ogni trimestre e cancella gli account di chi è andato via.

5. Non installare software di cui non ti fidi, e rimuovi ciò che non usi

I moduli sono la porta più comune da cui entrano gli attaccanti, e un modulo vulnerabile può essere sfruttato anche se non lo usi attivamente. Due regole coprono gran parte del rischio. Prima: installa solo moduli da fonti fidate: marketplace ufficiale PrestaShop Addons o sviluppatori consolidati con supporto reale e track record. I moduli nulled (moduli a pagamento crackati e distribuiti gratis) contengono quasi sempre una backdoor; l'economia lo rende ovvio: nessuno regala software a pagamento per gentilezza. Seconda: rimuovi i moduli che non usi. Non solo disabilitare: i moduli disabilitati possono lasciare file raggiungibili su disco, quindi disinstalla ed elimina i moduli inutilizzati per rimuovere quella superficie di attacco. Se non l'hai usato in sei mesi e non lo userai, va via.

Il livello successivo: traffico che non hai chiesto

Quando le basi sono chiuse, la cosa successiva che molti owner notano è traffico indesiderato: bot che martellano la pagina login, scraper, spam da moduli contatto e recensioni, qualche visitatore abusivo. Niente di tutto questo richiede per forza un developer; è soprattutto configurazione e strumenti giusti.

• Bot cattivi e crawler indesiderati. Non tutti i bot sono cattivi (quello di Google lo vuoi), quindi l'obiettivo è filtrare, non bloccare tutto. Il how-to pratico è in visitor control: bloccare bot cattivi e traffico indesiderato.
• Individui problematici. Quando è una persona specifica — fraudster, chargeback seriale, cliente abusivo — vuoi catturare informazioni extra sugli ordini e bannare per IP. Trattato in customer extra info e ban IP.
• Spam sui form. Form contatto, registrazione account e recensioni attirano spam bot. Un reCAPTCHA ferma i bot senza far saltare ostacoli ai clienti reali: vedi reCAPTCHA per PrestaShop.
• Il flood "?q=" della faceted search. Un tema più tecnico da conoscere: crawler aggressivi possono trasformare i filtri layered navigation di PrestaShop in carico denial-of-service accidentale. Se lo store sembra lento sotto traffico bot, leggi sopravvivere al flood ?q=.

Il livello server (dove potresti volere aiuto)

Parte dell'hardening vive sotto PrestaShop, a livello web server e file system. Puoi farlo da solo, ma è il layer in cui ha più senso chiedere all'host o a un developer se non sei sicuro: una regola .htaccess sbagliata può mandare offline il sito.

Versione breve: i permessi file dovrebbero essere 755 per le directory e 644 per i file, mai 777, e il file che contiene la password database (app/config/parameters.php su PrestaShop 1.7 e 8, o config/settings.inc.php su legacy 1.6) dovrebbe essere ancora più stretto. Il tuo .htaccess dovrebbe bloccare l'accesso pubblico diretto a cartelle come /app/config/, /var/ e /vendor/, e impedire l'esecuzione PHP nelle cartelle upload, così se qualcosa di sporco viene caricato, non può girare. Il .htaccess predefinito di PrestaShop è un punto di partenza, non una configurazione finita. Il set completo di regole, copiabile, è in PrestaShop .htaccess: regole sicurezza e performance.

Su Apache/vhost access, la regola per bloccare esecuzione negli upload deve essere esplicita. I path sotto corrispondono a una document root PrestaShop comune; adattali al tuo server.

# Apache: stop uploaded PHP from executing
<Directory "/var/www/html/img">
    php_admin_flag engine off
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

<Directory "/var/www/html/upload">
    php_admin_flag engine off
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

Una dashboard è utile solo dopo che le basi gratuite di hardening sono al loro posto.

Se vuoi capire da quale tipo di attacco difende tutto questo hardening server — come un card-skimmer reale entra davvero in uno store PrestaShop e ruba dati di pagamento — il walkthrough in anatomia di un attacco in stile Magecart rende concreto ciò che sembra astratto. Vale la pena leggerlo una volta, anche solo perché il resto smetta di sembrare teorico.

Il layer recovery: backup che hai davvero testato

I backup non sono una misura di sicurezza: sono una misura di recovery, e questa distinzione cambia come li tratti. Nessun backup ferma un attacco. Buoni backup significano che un attacco non finisce il tuo business. Tre abitudini separano una strategia backup reale da una falsa sensazione di sicurezza:

• Automatizzala. I backup manuali si saltano e si dimenticano. Un cron notturno che scarica il database e lo copia off-server, in un posto dove una compromissione del web server non può cancellarlo, è la base.
• Testa il restore. Un backup mai ripristinato è solo un file dal contenuto sconosciuto. Ripristina su staging una volta a trimestre. Non vuoi che il primo restore della tua vita sia durante un incidente live.
• Mantieni più punti di ripristino. Giornalieri per l'ultimo mese, settimanali per sei mesi. Alcuni attacchi, soprattutto manomissioni silenziose del database, non vengono notati per settimane, e ti serve un punto di prima che iniziassero.

Se succede il peggio

Anche uno store ben protetto può essere violato, e l'istinto sbagliato nella prima ora fa danni reali: persone che cancellano file (distruggendo le prove di cui hanno bisogno) o provano a pulire chirurgicamente malware che non troveranno mai tutto. C'è una sequenza corretta: isolare, preservare, identificare il punto di ingresso, ripristinare da backup pulito, ruotare ogni credenziale e rispettare gli obblighi di notifica (il GDPR richiede notifica entro 72 ore dalla consapevolezza di un breach che coinvolge dati personali). Non provare a ricordarla sotto pressione: abbiamo scritto il playbook calmo, passo-passo, da seguire quando conta: cosa fare se il tuo store viene hackerato.

Dove si inseriscono i moduli mypresta.rocks

Gran parte di questa pagina costa solo attenzione: aggiornamenti, 2FA, permessi sensati, backup reali. Dove un modulo guadagna il posto è nei layer tediosi o impossibili da fare a mano: monitorare continuamente i file per modifiche che non hai fatto, filtrare traffico ostile in tempo reale, e mantenere corretti cookie e consent senza rompere lo storefront. I nostri moduli sicurezza esistono per automatizzare esattamente quei lavori, così non li fai manualmente a mezzanotte: il beneficio è una cosa in meno da monitorare per un owner non tecnico, e modifiche che altrimenti perderesti emergono su una dashboard invece che in un report incidente. Sono un layer sopra le basi gratuite qui, non un sostituto. Chiudi prima le porte gratuite; poi usa tooling per le parti che richiedono davvero sorveglianza continua.

L'abitudine che tiene insieme tutto

La sicurezza non è una funzione che attivi una volta e dimentichi: è manutenzione, come tenere accurato il catalogo o onesti i conteggi stock. Gli owner che evitano problemi non sono quelli che hanno comprato più software; sono quelli che impostano un promemoria ricorrente. Una volta a trimestre, venti minuti: conferma che PrestaShop e i moduli siano aggiornati, controlla che la 2FA sia attiva per tutti, rimuovi account di ex dipendenti e, soprattutto, verifica che un backup si ripristini davvero. Venti minuti ogni tre mesi costano infinitamente meno del recupero da un breach, e trasformano l'argomento da fonte di ansia a routine a cui pensi appena.

Se vuoi lo stesso terreno coperto come checklist da spuntare invece che come visita guidata, il pezzo companion è la checklist completa di hardening sicurezza PrestaShop. Parti da lì se conosci già i concetti e vuoi solo assicurarti che non manchi nulla.