Knowledge Base Guide

Sicurezza PrestaShop: La checklist completa

Guida completa alla sicurezza PrestaShop — hardening server, protezione admin, audit moduli, sicurezza database e risposta agli incidenti.

Sicurezza di PrestaShop: La Checklist Completa

Ogni settimana, migliaia di negozi PrestaShop vengono compromessi. I proprietari lo scoprono quando Google segnala il loro sito, quando i clienti denunciano carte rubate, o quando la homepage reindirizza verso spam. Il danno è reale: mancati ricavi, fiducia distrutta, responsabilità GDPR e settimane di ripristino.

Questa guida nasce da anni di esperienza nel ripulire negozi hackerati. Ogni raccomandazione affronta una vulnerabilità reale che abbiamo visto sfruttata in produzione. Seguitela dall’inizio alla fine.

1. Perché i Negozi PrestaShop Vengono Hackerati

SQL Injection nei Moduli di Terze Parti

Questo è il vettore di attacco numero uno, e non è nemmeno un confronto. I moduli di sviluppatori inesperti spesso passano l’input dell’utente direttamente nelle query SQL. Un attaccante invia una richiesta manipolata al front controller di un modulo ed estrae l’intero database. La vulnerabilità non è quasi mai nel core di PrestaShop — è nei moduli.

Attacco Brute Force al Pannello di Amministrazione

PrestaShop non ha un sistema di rate limiting integrato. Un attaccante che conosce il nome della directory admin può provare migliaia di combinazioni di password al minuto. Qualsiasi account che usa admin123 o il nome dell’azienda verrà violato in pochi minuti.

Vulnerabilità nel Caricamento File

Alcuni moduli consentono il caricamento di file senza un’adeguata validazione. Un attaccante carica una shell PHP mascherata da immagine, vi accede tramite il browser e ottiene il controllo completo del server.

PHP e Software Obsoleti

Le versioni PHP a fine vita hanno vulnerabilità documentate pubblicamente con exploit funzionanti. Lo stesso vale per versioni obsolete di PrestaShop, Apache e MySQL.

File di Configurazione Esposti

Server mal configurati servono file .env, directory .git e configurazioni YAML a chiunque li richieda — rivelando credenziali del database e chiavi di crittografia.

Verifica della realtà: La maggior parte dei proprietari pensa “il mio negozio è troppo piccolo per essere preso di mira.” Gli scanner automatizzati non si preoccupano delle dimensioni. Scansionano ogni IP su internet. Se utilizzi PrestaShop, sei un bersaglio.

2. Sicurezza a Livello di Server

Versione e Configurazione PHP

Utilizza la versione PHP più recente supportata dal tuo PrestaShop — PHP 8.1+ per PS 8.x, PHP 8.1-8.4 per PS 9.x. Non utilizzare mai una versione a fine vita.

Impostazioni chiave di hardening per php.ini:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen
expose_php = Off
allow_url_include = Off
display_errors = Off
log_errors = On
session.cookie_httponly = 1
session.cookie_secure = 1
session.use_strict_mode = 1
session.cookie_samesite = Lax
open_basedir = /var/www/html:/tmp:/usr/share/php
Nota: Alcuni moduli necessitàno di exec() per l’elaborazione immagini o la generazione PDF. Se un modulo smette di funzionare, riabilita solo la funzione specifica richiesta.

Permessi dei File

  • Directory: 755 — proprietario lettura/scrittura/esecuzione, altri lettura/esecuzione
  • File: 644 — proprietario lettura/scrittura, altri sola lettura
  • File di configurazione: 400 — app/config/parameters.php dovrebbe essere in sola lettura per il proprietario
chown -R www-data:www-data /var/www/html/prestashop
find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chmod 400 /var/www/html/prestashop/app/config/parameters.php

# Writable directories PrestaShop needs
chmod -R 775 /var/www/html/prestashop/var/cache
chmod -R 775 /var/www/html/prestashop/var/logs
chmod -R 775 /var/www/html/prestashop/img
chmod -R 775 /var/www/html/prestashop/upload
chmod -R 775 /var/www/html/prestashop/download

Non impostare mai nulla a 777. Se un tutorial ti dice di eseguire chmod 777, cerca un tutorial migliore.

Configurazione SSL/TLS

Abilita SSL in PrestaShop (Parametri Negozio > Generale), poi aggiungi gli header HSTS:

# Apache .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Nginx
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$server_name$request_uri;
}
server {
    listen 443 ssl http2;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

Disabilita il Listing delle Directory e Rafforza .htaccess

Aggiungi queste regole al tuo .htaccess principale:

Options -Indexes

# Block sensitive file types
<FilesMatch "\.(env|yml|yaml|log|sql|bak|old|orig|save|swp|dist|config|ini|phps)$">
    Require all denied
</FilesMatch>

# Block hidden files and directories (.git, .env, etc.)
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule (^\.|/\.) - [F]
</IfModule>

# Block composer files
<FilesMatch "^(composer\.json|composer\.lock)$">
    Require all denied
</FilesMatch>

# Block config, vendor, and log directories
<IfModule mod_rewrite.c>
    RewriteRule ^config/ - [F]
    RewriteRule ^vendor/ - [F]
    RewriteRule ^var/logs/ - [F]
    RewriteRule ^app/config/ - [F]
</IfModule>

# Block PHP execution in upload directories
<Directory "/var/www/html/prestashop/upload">
    <FilesMatch "\.ph(p[3457]?|t|tml)$">
        Require all denied
    </FilesMatch>
</Directory>

<Directory "/var/www/html/prestashop/img">
    <FilesMatch "\.ph(p[3457]?|t|tml)$">
        Require all denied
    </FilesMatch>
</Directory>

Equivalente Nginx:

location ~* \.(env|yml|yaml|log|sql|bak|old|swp|dist|config|ini)$ { deny all; return 404; }
location ~ /\. { deny all; return 404; }
location ~* ^/(upload|img|download)/.*\.php$ { deny all; return 404; }
location ~* ^/(config|vendor|var/logs|app/config)/ { deny all; return 404; }
autoindex off;
Verifica: Dopo aver aggiunto queste regole, prova ad accedere a https://yourshop.com/.env e https://yourshop.com/app/config/parameters.php nel tuo browser. Dovresti ottenere un errore 403 o 404 — mai il contenuto reale.

3. Sicurezza dell’Admin di PrestaShop

Rinomina la Directory Admin

PrestaShop genera un nome casuale per la directory admin durante l’installazione. Non rinominarla mai in admin, backoffice o panel. Se è prevedibile, cambiala:

mv /var/www/html/prestashop/admin /var/www/html/prestashop/admin-x7k9m2p4
rm -rf /var/www/html/prestashop/var/cache/*

Usa almeno 10 caratteri casuali. Salva l’URL nei preferiti — non deve essere facile da ricordare.

Password Robuste e 2FA

Ogni account admin deve utilizzare una password unica di almeno 16 caratteri generata da un password manager. Nessuna eccezione.

Abilita l’autenticazione a due fattori per tutti gli account (Parametri Avanzati > Amministrazione). PrestaShop 1.7.6+ supporta Google Authenticator nativamente. Questa singola misura blocca la stragrande maggioranza degli attacchi brute force.

Limita l’Accesso Admin per IP

Se il tuo team lavora da IP fissi, limita l’accesso admin di conseguenza:

# .htaccess inside admin directory
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
    RewriteCond %{REMOTE_ADDR} !^198\.51\.100\.20$
    RewriteRule .* - [F,L]
</IfModule>

Se utilizzi una VPN, limita l’accesso all’IP della VPN — i dipendenti possono lavorare da qualsiasi luogo rimanendo comunque limitati per IP.

Disabilita gli Account Dipendenti Non Necessari

Controlla regolarmente gli account dipendenti (Parametri Avanzati > Team > Dipendenti):

  • Elimina gli account di ex dipendenti e collaboratori
  • Rimuovi gli account di test dalla configurazione iniziale
  • Assicurati che ogni dipendente abbia il profilo minimo necessario — il personale di magazzino non ha bisogno di SuperAdmin

Monitoraggio degli Accessi Admin

Configura fail2ban per la protezione contro il brute force:

# /etc/fail2ban/filter.d/prestashop-admin.conf
[Definition]
failregex = ^<HOST> -.*"POST .*/admin.*/index\.php\?controller=AdminLogin.*" (200|302)

# /etc/fail2ban/jail.d/prestashop.conf
[prestashop-admin]
enabled = true
filter = prestashop-admin
logpath = /var/log/apache2/access.log
maxretry = 5
findtime = 600
bantime = 3600

4. Sicurezza dei Moduli

I moduli sono la superficie di attacco più ampia in qualsiasi installazione PrestaShop. Tratta ogni modulo come un potenziale rischio fino a prova contraria.

Installa Solo da Fonti Affidabili

Fonti sicure: PrestaShop Addons Marketplace, sviluppatori affermati con una comprovata esperienza e moduli open-source ben mantenuti su GitHub.

Non installare mai moduli da siti “nulled” o “download gratuito”, sviluppatori sconosciuti o post casuali sui forum.

Attenzione: I moduli nulled (piratati) sono il modo più veloce per farsi hackerare. Gli attaccanti iniettano backdoor in moduli legittimi e li distribuiscono gratuitamente. La backdoor dà loro il controllo su ogni negozio che li installa. Abbiamo visto questo scenario centinaia di volte. Non esistono eccezioni.

Verifica il Codice dei Moduli

Prima di installare qualsiasi modulo, cerca questi segnali d’allarme:

# Dangerous � arbitrary code execution
eval($variable)
eval(base64_decode($something))
assert($user_input)

# Dangerous � remote code loading
file_get_contents('http://external-domain.com/...')
include('http://...')

# Dangerous � unsanitized SQL
"SELECT * FROM ps_table WHERE id = " . $_GET['id']
Db::getInstance()->execute("... " . $_POST['value'] . " ...")

Il codice sicuro utilizza query parametrizzate e i metodi di validazione di PrestaShop:

// SAFE: Cast to integer, use pSQL()
$id = (int)Tools::getValue('id');
$name = pSQL(Tools::getValue('name'));

Mantieni i Moduli Aggiornati

  • Controlla gli aggiornamenti almeno settimanalmente
  • Iscriviti ai bollettini di sicurezza degli sviluppatori
  • Segui gli avvisi di sicurezza di Friends of Presta per i CVE dei moduli PrestaShop
  • Effettua sempre un backup prima di aggiornare

Rimuovi Completamente i Moduli Inutilizzati

Disabilitare un modulo non è sufficiente. I file di un modulo disabilitato esistono ancora sul tuo server e i suoi front controller rimangono accessibili tramite URL diretto. Se ha una vulnerabilità, la disabilitazione non offre alcuna protezione.

# Uninstall via Back Office, then delete the files
rm -rf /var/www/html/prestashop/modules/unused_module

Esamina ora la tua lista di moduli. Se hai installato qualcosa per fare una prova sei mesi fa — cancellalo. Ogni modulo inutilizzato è una superficie di attacco non necessaria.

Controlla i Permessi dei Moduli

find /var/www/html/prestashop/modules -type d -exec chmod 755 {} \;
find /var/www/html/prestashop/modules -type f -exec chmod 644 {} \;

5. Sicurezza del Database

Non Usare Mai Root per l’Applicazione

Crea un utente dedicato con permessi minimi:

CREATE USER 'prestashop_user'@'localhost' IDENTIFIED BY 'long-random-password';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER,
      CREATE TEMPORARY TABLES, LOCK TABLES
      ON prestashop_db.* TO 'prestashop_user'@'localhost';
FLUSH PRIVILEGES;

Se un attaccante sfrutta una SQL injection, un utente con permessi limitati riduce il danno. L’utente root può accedere ad altri database, leggere file del server ed eseguire comandi di sistema.

Backup Regolari

# Crontab entries
# Database backup � daily at 3 AM
0 3 * * * mysqldump -u backup_user -p'password' prestashop_db | gzip > /backups/db/ps_$(date +\%Y\%m\%d).sql.gz

# File backup � daily at 3:30 AM
30 3 * * * tar -czf /backups/files/ps_files_$(date +\%Y\%m\%d).tar.gz /var/www/html/prestashop/

# Cleanup backups older than 30 days
0 4 * * * find /backups/ -name "*.gz" -mtime +30 -delete

Regole fondamentali:

  • Conserva i backup fuori dal server — se il server viene compromesso, anche i backup locali lo saranno
  • Testa i tuoi backup mensilmente — ripristina in un ambiente di test e verifica che il sito funzioni
  • Crittografa prima di trasferire fuori sede — i dump contengono dati personali dei clienti
  • Conserva oltre 30 giorni di backup giornalieri — alcune compromissioni non vengono scoperte immediatamente

Metti in Sicurezza phpMyAdmin (o Rimuovilo)

L’opzione più sicura: non installare phpMyAdmin in produzione. Usa invece i tunnel SSH:

# From your LOCAL machine
ssh -L 3307:localhost:3306 user@yourserver.com
# Then connect your local MySQL client to localhost:3307

Se devi per forza eseguire phpMyAdmin: limita l’accesso per IP, usa un percorso URL casuale, abilita l’autenticazione HTTP Basic e disabilita il login come root:

$cfg['Servers'][$i]['AllowRoot'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;

6. Monitoraggio e Rilevamento

Monitoraggio dell’Integrità dei File

Gli attaccanti modificano i file — iniettando backdoor, aggiungendo shell nelle directory di upload o alterando .htaccess. Rileva le modifiche con un cron job giornaliero:

#!/bin/bash
# /usr/local/bin/prestashop-integrity-check.sh
SHOP_DIR="/var/www/html/prestashop"
BASELINE="/var/backups/prestashop-file-hashes.txt"
CURRENT="/tmp/prestashop-file-hashes-current.txt"
ALERT_EMAIL="admin@yourdomain.com"

find "$SHOP_DIR" -type f \
    -not -path "*/var/cache/*" \
    -not -path "*/var/logs/*" \
    -not -path "*/img/p/*" \
    -not -path "*/img/c/*" \
    -exec md5sum {} \; | sort > "$CURRENT"

if [ -f "$BASELINE" ]; then
    DIFF=$(diff "$BASELINE" "$CURRENT")
    if [ -n "$DIFF" ]; then
        echo "$DIFF" | mail -s "ALERT: PrestaShop files modified" "$ALERT_EMAIL"
    fi
fi

Genera la baseline dopo un’installazione pulita, poi questo script ti invia un’email ogni volta che i file cambiano in modo imprevisto.

Monitoraggio dei Log

Analizza i log di accesso alla ricerca di pattern di attacco:

# SQL injection attempts
grep -iE "(union\s+select|or\s+1=1|information_schema)" /var/log/apache2/access.log

# File inclusion attempts
grep -iE "(etc/passwd|\.\.\/\.\.\/)" /var/log/apache2/access.log

# Direct module file access (potential exploit attempts)
grep -E "modules/.*/ajax|modules/.*/api" /var/log/apache2/access.log

Configura riepiloghi giornalieri dei log tramite cron, oppure invia i log a un sistema centralizzato come Graylog o Papertrail per avvisi in tempo reale.

Monitoraggio dell’Uptime

  • Usa UptimeRobot, Hetrix Tools o Uptime Kuma self-hosted
  • Monitora sia la homepage che la pagina di checkout
  • Verifica il contenuto specifico della pagina, non solo l’HTTP 200 — una pagina defacciata restituisce comunque 200
  • Controlla ogni 1-5 minuti con avvisi via email, SMS o Slack

Avvisi di Login Admin

Ricevi una notifica per ogni accesso admin con un semplice hook:

public function hookActionAdminLoginControllerLoginAfter($params)
{
    $employee = $params['employee'];
    $ip = Tools::getRemoteAddr();

    Mail::Send(
        (int)Configuration::get('PS_LANG_DEFAULT'),
        'alert_admin_login',
        "Admin Login: {$employee->email} from {$ip}",
        ['{body}' => "Employee: {$employee->email}\nIP: {$ip}\nTime: " . date('Y-m-d H:i:s')],
        'security@yourdomain.com',
        'Security Alert'
    );
}

7. Cosa Fare Se Sei Stato Hackerato

Risposta Immediata (Primi 30 Minuti)

  • Non cancellare ancora nulla — hai bisogno dei file per l’analisi forense
  • Metti il negozio offline con una pagina di manutenzione per fermare il danno in corso
  • Cambia TUTTE le password: SSH, FTP, database, account admin, pannello di hosting, chiavi del gateway di pagamento
  • Esegui un backup dello stato compromesso — etichettalo come “compromesso” per un’analisi successiva
  • Notifica il tuo processore di pagamento se gestisci i pagamenti direttamente
# Quick maintenance mode
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR\.IP\.ADDRESS$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule .* /maintenance.html [R=503,L]

Trovare la Backdoor

Gli attaccanti lasciano sempre delle backdoor per rientrare. Ripulire l’hack visibile senza trovare la backdoor significa essere compromessi di nuovo entro pochi giorni.

# Search for backdoor patterns
grep -rn "eval(" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"
grep -rn "base64_decode" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"
grep -rn "shell_exec\|passthru\|system(" /var/www/html/prestashop/ --include="*.php" | grep -v "vendor\|cache"

# Find recently modified PHP files
find /var/www/html/prestashop/ -name "*.php" -mtime -7 -not -path "*/cache/*"

# Find PHP files in directories where they should not exist
find /var/www/html/prestashop/img/ -name "*.php"
find /var/www/html/prestashop/upload/ -name "*.php"

# Check for obfuscated code (very long single lines)
find /var/www/html/prestashop/ -name "*.php" -exec awk 'NR==1 && length>5000' {} +

Controlla anche il database:

SELECT id_cms, meta_title FROM ps_cms_lang WHERE content LIKE '%<?php%' OR content LIKE '%eval(%';
SELECT * FROM ps_employee ORDER BY date_add DESC LIMIT 10;

Processo di Ripristino

  1. Determina il punto di ingresso dai log di accesso — cerca richieste POST insolite ai controller dei moduli intorno al momento della compromissione
  2. Ripristina da un backup pulito se disponibile. Verifica che il backup sia precedente alla compromissione.
  3. Se non esiste un backup pulito: sostituisci tutti i file core con un download pulito della tua esatta versione PS, reinstalla tutti i moduli dalle fonti originali, mantieni solo il tuo tema e la directory img/ (scansionali accuratamente)
  4. Scansiona il database alla ricerca di contenuti iniettati in ps_configuration, ps_cms_lang e ps_meta_lang
  5. Aggiorna tutto — core, moduli, PHP, MySQL, sistema operativo

Prevenzione Dopo la Pulizia

  • Rimuovi o correggi la vulnerabilità specifica che è stata sfruttata
  • Monitora intensamente per il primo mese — gli attaccanti spesso tentano di tornare
  • Considera un WAF (Cloudflare free tier, Sucuri o ModSecurity)
  • Se i dati di pagamento sono stati potenzialmente compromessi, consulta un avvocato sugli obblighi di notifica GDPR (scadenza di 72 ore)
Dura verità: Se non riesci a determinare come l’attaccante è entrato, presumi che entrerà di nuovo. Un audit di sicurezza professionale costa una frazione di una seconda violazione.

8. Checklist di Sicurezza

Stampa questa lista e segui ogni punto. Ogni elemento non spuntato è un potenziale punto di ingresso.

Server e PHP

  • La versione PHP è attuale e supportata
  • Le funzioni PHP pericolose sono disabilitate
  • expose_php = Off
  • display_errors = Off in produzione
  • allow_url_include = Off
  • Cookie di sessione: HttpOnly, Secure, SameSite
  • open_basedir impostato
  • Sistema operativo, MySQL e web server aggiornati
  • Autenticazione SSH via chiave abilitata, autenticazione via password disabilitata
  • Firewall configurato (solo le porte necessarie aperte)

File System

  • Directory: 755, File: 644
  • parameters.php: 400
  • Nessun file impostato a 777
  • Esecuzione PHP bloccata in upload/, img/, download/
  • Listing delle directory disabilitato
  • .env, .git, YAML, file di configurazione bloccati dal web
  • vendor/ e var/logs/ bloccati dal web

SSL e HTTPS

  • Certificato SSL valido con rinnovo automatico
  • Redirect da HTTP a HTTPS attivo
  • Header HSTS configurato
  • SSL abilitato in PrestaShop (tutte le pagine)
  • Nessun avviso di contenuto misto

Pannello Admin

  • La directory admin ha un nome casuale
  • Tutte le password di almeno 16 caratteri da un password manager
  • 2FA abilitata per tutti gli account
  • Accesso admin limitato per IP (se possibile)
  • Account non necessari eliminati
  • Ogni dipendente ha i permessi minimi necessari
  • Protezione brute force (fail2ban o equivalente)

Moduli

  • Tutti i moduli da fonti affidabili
  • Nessun modulo nulled/piratato
  • Tutti i moduli aggiornati
  • Moduli inutilizzati eliminati (non solo disabilitati)
  • Codice dei moduli verificato per eval() e SQL non sanitizzato
  • Iscrizione agli avvisi di sicurezza

Database

  • Utente database dedicato (non root)
  • Permessi minimi concessi
  • Password del database robusta (oltre 20 caratteri)
  • MySQL in ascolto solo su localhost
  • phpMyAdmin rimosso o limitato per IP
  • Prefisso tabelle cambiato dal predefinito ps_

Backup

  • Backup giornalieri automatici del database
  • Backup giornalieri automatici dei file
  • Backup conservati fuori dal server
  • Backup crittografati prima del trasferimento
  • Conservazione di oltre 30 giorni
  • Ripristino testato negli ultimi 30 giorni

Monitoraggio

  • Monitoraggio integrità dei file attivo
  • Log di accesso monitorati per pattern di attacco
  • Monitoraggio uptime con verifica del contenuto
  • Avvisi di login admin abilitati
  • Header di sicurezza configurati

Preparazione agli Incidenti

  • Piano di risposta agli incidenti documentato
  • Contatti di hosting e processore di pagamento accessibili
  • Processo di notifica GDPR documentato
  • Pagina di manutenzione pronta per il deploy
  • Tutte le password critiche in un password manager

La sicurezza è un processo continuo, non una configurazione una tantum. Pianifica una revisione trimestrale. Il tempo che investi ora è insignificante rispetto al costo del recupero da una violazione. Inizia con gli elementi a maggiore impatto: aggiorna tutto, abilita il 2FA, rimuovi i moduli inutilizzati e configura i backup. Poi prosegui con il resto.

I tuoi clienti ti affidano i loro dati personali. Onora questa fiducia.

More guides available

Browse our knowledge base for more practical PrestaShop tutorials, or reach out if you need help.

Browse Knowledge Base Contact Us
Back to top