Come fare un self-audit del tuo negozio PrestaShop — Modulo gratuito Security Scan

Due modi per controllare il tuo negozio

Per una lettura rapida in pochi secondi, usa il nostro Security Scanner pubblico: inserisci l'URL del tuo negozio e lui rileva passivamente le versioni di PrestaShop e PHP, verifica se quella versione è esposta pubblicamente o a fine vita, e ispeziona gli header di sicurezza HTTPS — nessuna installazione, nulla da configurare. Legge solo ciò che qualsiasi visitatore vede già.

Questo è anche il suo limite. Un check pubblico non può dire quali versioni dei moduli usi realmente, quali sono i permessi dei tuoi file, se la modalità debug è attiva o se un backup .sql è rimasto nella tua webroot — ed è proprio quest'ultima categoria a causare la maggior parte delle violazioni dei negozi PrestaShop. Per questo, installa il modulo gratuito Security Scan: analizza il tuo negozio dall'interno, dove il consenso è implicito, perché il negozio è tuo. Questa guida ti mostra come eseguirlo, come leggere il report e — con comandi reali — come correggere ciò che trova. Come riferimento approfondito per l'hardening, la nostra checklist di hardening della sicurezza PrestaShop va ancora oltre.

Cosa controlla una scansione locale

Il report è raggruppato per area — prima i controlli confermati (versioni, file esposti), poi quelli euristici (malware e codice), chiaramente contrassegnati. Ogni rilevazione spiega cosa è stato trovato, perché è importante e come correggerlo.

I gruppi malware e codice sono euristici di proposito — ipotesi ragionate che ogni tanto segnaleranno qualcosa di innocuo. Preferiamo mostrarti un falso positivo che puoi scartare in dieci secondi piuttosto che perderci silenziosamente una web shell.

Ogni rilevazione è verificabile. Ogni corrispondenza di versione e CVE rimanda direttamente all'advisory ufficiale — il record CVE o il GitHub Security Advisory del produttore — e riporta un livello di confidenza, così puoi verificare ogni segnalazione da solo invece di crederci sulla parola. Dove lo scanner può solo dedurre qualcosa, o non può confermare un'impostazione dall'esterno, lo dice chiaramente e le assegna un punteggio basso. È costruito per essere accurato, non allarmista.

Come eseguirlo

Installa e attiva il modulo gratuito Security Scan, poi apri Configura → Security Scan → Scan & Report e clicca su Run scan now. Una scansione tipica richiede pochi secondi. I controlli si limitano a leggere i file, la configurazione e il database del negozio più i tuoi URL pubblici; il modulo scrive solo il proprio record nello storico delle scansioni, quindi non modifica mai file del negozio, impostazioni, prodotti, ordini o clienti — sicuro anche su un negozio in produzione.

Preferisci la riga di comando, o vuoi automatizzarlo? Puoi avviare la stessa scansione locale da un contesto PrestaShop inizializzato (la guardia gli impedisce di girare via web se dimentichi il file sul server):

<?php
// scan-now.php — run from the CLI only; delete the file if you place it in the shop root
if (PHP_SAPI !== 'cli') {
    http_response_code(403);
    exit;
}

require __DIR__ . '/config/config.inc.php';
require __DIR__ . '/modules/mprsecurityscan/vendor/autoload.php';

$run = \MPRSecurityScan\Service\ScanRunner::runAndStore('manual');
printf("Score %d/100 (grade %s) — %d issues\n",
    $run['result']['score'], $run['result']['grade'], $run['result']['problem_count']);

Come leggere il tuo punteggio

Ottieni un unico numero su 100 e un voto in lettere. Il punteggio parte da 100 e perde punti per ogni problema reale, ponderato per gravità — un problema critico costa molto più di uno lieve. Vengono mostrati anche i controlli superati, così vedi cosa è stato effettivamente verificato.

• Critico −30 ciascuno — sfruttabile ora, o esposizione confermata. Da correggere oggi.
• Alto −15 — serio; da correggere questa settimana.
• Medio −7 — lacune significative di hardening o di igiene.
• Basso −3 — miglioramenti minori.

Il tutto si traduce in un voto — A 90+, B 75+, C 60+, D 40+, F sotto 40. Considera il punteggio uno strumento di prioritizzazione, non una garanzia: un punteggio alto significa che lo scanner non ha trovato problemi noti in ciò che riesce a vedere.

Esempio pratico: una directory .git esposta

È una delle rilevazioni più comuni — e più pericolose. Se hai fatto il deploy con git clone o git pull nella tua webroot, l'intera cartella .git (con tutta la cronologia dei sorgenti e ogni segreto mai committato) potrebbe essere scaricabile. Lo scanner lo conferma richiedendo davvero /.git/HEAD via HTTP e verificando che la risposta assomigli a metadati di un VCS.

Critico — i metadati del VCS sono raggiungibili pubblicamente. Lo scanner ha confermato che /.git/HEAD restituisce metadati VCS via HTTP.

Correggilo in due passaggi. Prima, dalla root del tuo negozio, fai il backup dei metadati e rimuovili (le guardie assicurano che nulla venga cancellato se il backup non è riuscito):

# run from your shop root
set -eu

paths=()
[ -d .git ] && paths+=(.git)
[ -d .svn ] && paths+=(.svn)

if [ "${#paths[@]}" -gt 0 ]; then
  tar czf "$HOME/vcs-metadata-backup-$(date +%F-%H%M%S).tgz" "${paths[@]}"
  rm -rf "${paths[@]}"
fi

Poi assicurati che il web server rifiuti le directory con il punto, anche se una dovesse ricomparire. Apache (.htaccess o vhost) — questo nega i file con il punto e i percorsi di directory con il punto come /.git/HEAD, mantenendo però /.well-known/:

<FilesMatch "^\.">
  Require all denied
</FilesMatch>

RedirectMatch 404 "(^|/)\.(?!well-known(?:/|$))"

Oppure nginx:

location ^~ /.well-known/ {
    try_files $uri =404;
}

location ~ /\.(?!well-known(?:/|$)) {
    return 404;
}

Riesegui la scansione; la rilevazione dovrebbe sparire (l'URL ora restituisce 403/404). Se in quella cronologia è mai vissuto un segreto, ruotalo.

Cosa correggere per primo (con i comandi)

Lavora il report dall'alto verso il basso. Ecco le correzioni per le rilevazioni che vedrai più spesso.

Archivi di backup nella webroot

Uno store.sql o un backup.zip accanto a index.php è una copia completa del tuo negozio, a un solo tentativo di indovinare il nome. Elencali, poi sposta ogni corrispondenza fuori dalla docroot (mv -n non sovrascrive mai):

# review the list first
find . -maxdepth 2 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.bak' \) -ls

# then move every match out of the webroot
mkdir -p "$HOME/private-backups"
find . -maxdepth 2 -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.bak' \) \
  -exec mv -n -- {} "$HOME/private-backups/" \;

Directory /install residua

PrestaShop ti dice di eliminarla dopo l'installazione. Invece di cancellarla subito, mettila in quarantena (da eseguire dalla root del negozio):

# run from your shop root
set -eu
test -f config/config.inc.php

backup="$HOME/prestashop-install-dirs-$(date +%F-%H%M%S)"
mkdir -p "$backup"
[ -d install ] && mv install "$backup/"
[ -d install-dev ] && mv install-dev "$backup/"

Modalità debug lasciata attiva

La modalità sviluppatore espone stack trace e percorsi ai visitatori. Modifica la riga esistente in config/defines.inc.php (o config/defines_custom.inc.php) — non aggiungerne una seconda sotto:

<?php
// change the EXISTING _PS_MODE_DEV_ line to false (never true on a live shop)
define('_PS_MODE_DEV_', false);

Cartelle scrivibili da chiunque (0777)

Lo scanner segnala le directory a 0777. Ripristina permessi a privilegio minimo — mai chmod 777, e mantieni illeggibili i file di configurazione segreti (un parameters.php leggibile da tutti è di per sé una rilevazione). Da eseguire dalla root del negozio:

# run from your shop root; set these to your real PHP-FPM/web user + group
WEB_USER=www-data
WEB_GROUP=www-data

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

# lock down the secret config files: owned by the web user, readable by owner+group only
# (never world-readable — but still readable by the PHP process). Adjust owner/group above.
for f in app/config/parameters.php config/settings.inc.php; do
  [ -f "$f" ] || continue
  chown "$WEB_USER:$WEB_GROUP" "$f"
  chmod 640 "$f"
done

# only the writable dirs need to be owned by the web user
for dir in var/cache var/logs img upload download; do
  [ -d "$dir" ] || continue
  chown -R "$WEB_USER:$WEB_GROUP" "$dir"
  find "$dir" -type d -exec chmod 775 {} \;
  find "$dir" -type f -exec chmod 664 {} \;
done

.htaccess debole o mancante

Rigenera le regole protettive di PrestaShop dal Back Office (Parametri negozio → Traffico & SEO → Rigenera il file .htaccess), poi verifica che i file sensibili siano bloccati e che il directory listing sia disattivato. Una protezione minima:

<FilesMatch "(?i)(parameters\.php|settings\.inc\.php|\.env|composer\.(json|lock))$">
  Require all denied
</FilesMatch>

Options -Indexes

I limiti della sola rilevazione

Essere onesti sui limiti fa parte del buon uso di qualsiasi strumento di sicurezza: rileva i problemi, non li corregge al posto tuo; i controlli euristici possono segnalare cose innocue (verifica prima di eliminare); la copertura degli advisory è curata, non esaustiva; e non è un penetration test. Per il riferimento completo di remediation — hardening del server, blindatura dell'admin, database e monitoraggio — segui la checklist di hardening della sicurezza.

Quando smettere di scansionare e chiedere aiuto

Alcune rilevazioni significano che serve una persona, non uno strumento. File dall'aspetto di malware, qualsiasi cosa somigli a uno skimmer dei pagamenti, account admin che non riconosci, credenziali esposte o reinfezioni ripetute — quello è un incidente. Se preferisci affidarlo a noi, prenota un audit di sicurezza.

Quando hanno senso le correzioni automatiche

Lo scanner gratuito è volutamente usa-e-basta: lo esegui, lo leggi, correggi le cose a mano. Perfetto per un check-up occasionale. Se preferisci non farlo manualmente — o vuoi restare a posto — Security Revolution applica correzioni con un clic, blinda il tuo negozio, monitora l'integrità dei file del core, ti avvisa quando qualcosa cambia e gestisce un'intera flotta di negozi da un'unica dashboard. Le stesse rilevazioni; semplicemente agisce su di esse e continua a vigilare.

FAQ

La scansione invia i miei dati da qualche parte? Per una scansione autonoma da dashboard o da CLI, no — il report resta sul tuo server, e le uniche richieste in uscita sono auto-verifiche verso i tuoi stessi URL pubblici, protette contro l'accesso a indirizzi interni (SSRF). Se attivi esplicitamente il connettore di flotta opzionale, i risultati delle scansioni vengono inviati — su un canale firmato — all'hub che hai configurato.

Corregge i problemi automaticamente? No — questo modulo fa solo rilevazione. Le correzioni automatiche e il monitoraggio sono in Security Revolution.

È sicuro su un negozio in produzione? Sì. Legge i tuoi file, la configurazione e il database e scrive solo il proprio record nello storico delle scansioni — non modifica mai contenuti del negozio, impostazioni, prodotti, ordini o clienti.

Ogni quanto dovrei scansionare? Dopo ogni aggiornamento di PrestaShop o di un modulo, e almeno una volta al mese. La pagina Storico traccia il tuo punteggio nel tempo.

Può sostituire uno sviluppatore? No. È una prima passata rapida e utile che intercetta i rischi comuni e ben noti. Gli audit approfonditi e gli incidenti reali richiedono comunque un essere umano.

Letture correlate

• Hardening della sicurezza PrestaShop: la checklist completa — il complemento di remediation di questa pagina.
• Security Scan — il modulo gratuito descritto qui.
• Security Revolution — correzioni automatiche, hardening e monitoraggio dell'integrità dei file.