Sicurezza PrestaShop: rafforzamento, accessi e recupero

Cosa faremmo

Stabiliremmo prima se stai prevenendo un problema o rispondendo a prove di una compromissione. Per il rafforzamento ordinario della sicurezza, censisci ciò che usi già prima di scegliere strumenti: hosting, PrestaShop e PHP, moduli, integrazioni, personalizzazioni del tema, dati memorizzati, mercati e persone che necessitano di accesso. Un'integrazione di magazzino, un team di assistenza in viaggio e un modulo di pagamento incorporato impongono requisiti diversi. Mantieni i controlli già efficaci e affronta le lacune dimostrabili.

Se il negozio non può usare software mantenuto, confronta l'aggiornamento dell'installazione esistente con un'installazione di destinazione pulita e una migrazione controllata dei dati. Il percorso giusto dipende da codice personalizzato, sostituzioni dei moduli, tema, integrazioni e qualità dei dati. Rafforzare un negozio non supportato contiene rischi specifici durante questi lavori, ma non ripristina la manutenzione del progetto originale. Se sospetti una compromissione, conserva le prove e segui la sezione sulla risposta agli incidenti prima di considerare il negozio una copia iniziale sicura.

Per modifiche pianificate, usa una copia di staging protetta, prova i percorsi operativi interessati, registra come annullare la modifica e concorda un passaggio in produzione con un responsabile che ne controlli il risultato. Una migrazione di piattaforma o database richiede anche un piano per ordini e altre scritture ricevute durante la preparazione della copia.

Se vuoi una valutazione indipendente, il PrestaShop Security Audit & Hardening Report esamina l'esposizione concordata e fornisce un piano con priorità; implementazione e risanamento dopo un incidente hanno un ambito separato.

Parti da prevenzione, rilevamento e recupero

Proteggi il negozio a più livelli: software supportato, accessi individuali, permessi limitati, regole server, filtraggio del traffico, monitoraggio e backup ripristinabili. HTTPS protegge i dati in transito. Un backup aiuta il recupero. Nessuno dei due sostituisce le patch.

I rischi includono SQL injection nel core o nei moduli, credenziali dei dipendenti rubate, caricamenti vulnerabili, pacchetti dannosi e backup o configurazioni esposti. Un checkout può continuare a funzionare mentre JavaScript iniettato ruba dati. Anche un piccolo negozio ha bisogno di questi controlli.

1. Registra le versioni esatte di PrestaShop, PHP, database, tema e moduli.
2. Esegui il backup di file e database, poi dimostra di poterli ripristinare su una copia isolata.
3. Applica le correzioni di sicurezza in staging e verifica il checkout prima della produzione.
4. Assegna a ogni dipendente un account univoco, una password forte e un secondo fattore.
5. Esamina percorsi scrivibili, endpoint pubblici e avvisi di monitoraggio.

Assegna a ogni controllo un responsabile e una data di revisione. Rivedi gli accessi dopo cambi del personale e ripeti regolarmente la verifica più ampia. Proteggi lo staging con autenticazione e disattiva lì pagamenti reali, email ai clienti e integrazioni di produzione.

Mantieni PrestaShop e PHP supportati

Compatibilità e manutenzione di sicurezza sono questioni separate. PrestaShop da 8.0 a 8.2 supporta PHP solo fino a 8.1. PrestaShop 9.0 supporta PHP da 8.1 a 8.4; 9.1 supporta da 8.1 a 8.5. Anche la versione 9.2 supporta PHP da 8.1 a 8.5. Verifica la versione esatta e ogni modulo prima di cambiare PHP. Consulta la tabella di compatibilità e i requisiti 9.2.

Al 26 ottobre 2026, PHP 8.1 è già a fine ciclo di vita. Il supporto di sicurezza upstream è terminato il 31 dicembre 2025. PHP 7.4 ha terminato il supporto il 28 novembre 2022. Controlla il ciclo di vita PHP oltre alla compatibilità della piattaforma. Pianifica un aggiornamento della piattaforma se il negozio non può usare un ambiente mantenuto; convalida esplicitamente eventuali accordi di supporto esteso.

La manutenzione upstream regolare di PrestaShop 1.7 è terminata all'uscita di 9.0. Un hotfix eccezionale successivo non è manutenzione continuativa del ramo. Anche PrestaShop 1.6 è fuori dalla manutenzione ufficiale. Segui la politica di manutenzione e pianifica la migrazione.

Applica patch anche a sistema operativo, database, server web e moduli. Mantieni un inventario dei moduli e iscriviti agli avvisi dei fornitori e agli avvisi di sicurezza Friends of Presta. Un numero di versione da solo non dimostra l'applicabilità di un exploit specifico.

Usa la checklist di migrazione per pianificare i cambi tra versioni PHP e PrestaShop.

Prova la modifica e il ripristino

Per esempio, irrigidire le regole di caricamento può proteggere gli allegati dei clienti ma interrompere un modulo che li elabora tramite un endpoint legacy. Registra prima i percorsi reali usati dal modulo. Prova separatamente caricamenti normali e nomi di file eseguibili bloccati, affinché un'immagine prodotto funzionante non nasconda un flusso di allegati guasto.

1. Registra configurazione attuale, percorsi interessati, credenziali delle integrazioni e un punto di ripristino abbinato di file e database. Documenta il comportamento atteso prima di modificare qualsiasi cosa.
2. Crea la copia protetta con gli stessi gestori server, regole proxy, moduli e tema pertinenti. Limita l'accesso ai dati cliente copiati e sostituisci le destinazioni di produzione con servizi di prova o simulazioni controllate.
3. Applica una modifica logica alla volta. Cambiare contemporaneamente PHP, modulo e firewall rende più difficile attribuire un errore.
4. Prova azioni consentite e vietate: accesso e recupero del personale, tentativi fuori ruolo, navigazione del catalogo, caricamenti, checkout, notifiche di pagamento, rimborsi, attività pianificate e sincronizzazione dei partner, secondo il caso.
5. Prova il ritorno alla situazione precedente. Ripristinare un file di configurazione, annullare codice distribuito e ripristinare un database hanno conseguenze diverse; identifica cosa richiede la modifica e chi può farlo.
6. Concorda finestra di passaggio, controlli per procedere o fermarsi e criterio di ripristino. Se i dati passano tra installazioni, definisci come sospendere o riconciliare le scritture e gestire le notifiche di pagamento in arrivo.
7. Dopo il passaggio, controlla l'elaborazione degli ordini reali e il canale degli avvisi. Conserva risultati delle prove, impostazioni modificate e istruzioni di manutenzione per il rilascio successivo.

Un ripristino del database può cancellare ordini inseriti dopo il punto di ripristino. Per annullare una migrazione, concorda come riconciliare quegli ordini e i pagamenti presso i fornitori prima di tornare indietro. Mantieni protetto l'ambiente precedente finché lo conservi per il recupero.

Per un negozio legacy che richiede una piattaforma mantenuta, il PrestaShop Upgrade Service: Any Version to PrestaShop 9 valuta versione esistente, PHP, hosting, tema e moduli prima di un preventivo scritto, poi lavora su staging prima del passaggio in produzione.

Trova o cambia l'URL del back office

Il back office risiede in una cartella fisica sotto la radice del negozio. Se il negozio è installato sotto /shop/, includi quel percorso di base prima della cartella amministrativa. Usa SFTP, il gestore file dell'host o SSH per trovarla.

Cerca la radice del negozio contenente classes/, modules/ e themes/. I nomi candidati spesso iniziano con admin, ma una cartella rinominata può avere un altro nome. Esamina il suo index.php per l'inizializzazione amministrativa e la definizione di _PS_ADMIN_DIR_. Non è richiesta una sottocartella controllers/ al suo interno.

Il file standard app/config/parameters.php non memorizza il nome della cartella amministrativa. Mantieni privato il nome casuale esistente o rinomina la cartella effettiva durante una finestra di accesso coordinata. Nessuna impostazione standard del database deve essere modificata per corrispondervi.

1. Mantieni disponibile un accesso SFTP o hosting funzionante.
2. Chiedi ai colleghi di uscire, poi rinomina la cartella.
3. Aggiorna eventuali riferimenti personalizzati di proxy, firewall, attività pianificate o moduli al vecchio percorso.
4. Apri il nuovo URL HTTPS e verifica l'accesso.
5. Aggiorna preferiti e voci del gestore password. Controlla che il vecchio percorso non apra più il back office.

Un link simbolico dal vecchio nome mantiene raggiungibile quel punto d'ingresso. Un percorso privato riduce le scansioni occasionali ma richiede comunque autenticazione forte e restrizioni di accesso.

Password, autenticazione a due fattori e sessioni dei dipendenti

Nelle versioni moderne, apri Parametri avanzati > Team > Dipendenti, Profili e Permessi. In PrestaShop 1.6 queste pagine sono sotto Amministrazione. Assegna a ogni persona un account dipendente nominativo. Evita di condividere l'accesso del proprietario.

Usa password lunghe e uniche generate da un gestore password. Una password casuale di almeno 16 caratteri è una politica pratica. Cambia prontamente password compromesse o riutilizzate. La rotazione forzata di routine non sostituisce lunghezza e unicità. Il core moderno usa il proprio servizio Crypto Hashing con bcrypt e verifica degli hash legacy; non reimpostare password con MD5 diretto.

Il TOTP del back office richiede un modulo compatibile o un livello esterno di identità/accesso. Il core non fornisce l'interruttore TOTP universale descritto in molti vecchi tutorial. Anche un fornitore di identità esterno può imporre MFA individuale. TOTP riduce gli attacchi basati sulla sola password, ma un aggressore può inoltrare un codice corrente tramite phishing. Un'autenticazione WebAuthn/FIDO implementata correttamente offre un diverso livello di resistenza al phishing. Consulta le indicazioni NIST sull'autenticazione.

Prova registrazione e recupero prima di imporre il secondo fattore al team. Conserva i codici di recupero fuori dal telefono, controlla gli orologi di server e telefono e documenta la procedura di recupero dello strumento. Il core non ha colonne 2FA standard dei dipendenti da azzerare.

Security Revolution aggiunge TOTP per i dipendenti, codici di backup, controlli di accesso, gestione degli header di sicurezza e confronti dei file con una base di riferimento; segui la guida del modulo per configurazione e recupero.

Distingui scadenza del cookie e inattività

PS_COOKIE_LIFETIME_BO si misura in ore. Controlla la durata del cookie, non una politica generale di inattività. Accesso persistente e controlli di inattività differiscono per versione; PrestaShop 1.7.8 ha un controllo separato dell'ultima attività di un'ora nella modalità di accesso pertinente. Prova il comportamento effettivo di disconnessione.

PS_PASSWD_TIME_BACK è misurato in minuti e riguarda l'ultima generazione della password. Non garantisce un intervallo tra le richieste di email di reimpostazione. Aggiungi un limite separato alle richieste dove necessario.

Richiedi HTTPS ed esamina il cookie amministrativo effettivo per i flag Secure e HttpOnly e una politica SameSite appropriata. Le impostazioni dei cookie di sessione PHP non controllano necessariamente ogni cookie PrestaShop. Blocca le postazioni incustodite e revoca le sessioni quando un dispositivo o account è compromesso.

Verifica registrazione e recupero con un dipendente ordinario

1. Usa un dipendente identificato nel profilo di permessi previsto, anziché provare solo come SuperAdmin.
2. Completa la registrazione, poi esci e prova un nuovo accesso. Conferma che il percorso protetto non sia raggiungibile saltando la pagina del secondo fattore.
3. Prova il recupero documentato per dispositivo smarrito con una persona autorizzata disponibile ad aiutare. Conferma cosa invalida l'azione di recupero e come il dipendente registra un dispositivo sostitutivo.
4. Controlla la registrazione di ogni dipendente attivo, inclusi collaboratori e account usati solo occasionalmente. Definisci chi approva un'eccezione e quando termina.

CAPTCHA dei moduli cliente e autenticazione dei dipendenti sono ambiti separati. Installare una protezione per l'accesso alla vetrina non dimostra che sia coperto l'accesso al back office; prova il percorso effettivo dei dipendenti.

Limita l'accesso e rileva gli accessi falliti

Se il team usa un indirizzo stabile dell'ufficio o una VPN, limita il back office sul proxy o sul server. Mantieni un percorso di recupero autorizzato e prova da indirizzi consentiti e vietati. Con un reverse proxy, configura la gestione affidabile dell'IP cliente prima di usare regole IP.

Per Apache 2.4, il seguente è un esempio per una directory amministrativa il cui ufficio autorizzato usa la rete di documentazione indicata. Usa la tua rete approvata quando lo applichi.

Require ip 203.0.113.10
Require ip 198.51.100.0/24

Limita la frequenza degli errori di autenticazione con un meccanismo verificato sulla route di accesso della tua versione. Non dedurre l'errore da HTTP 200 o 302: tentativi riusciti e falliti possono condividere quei codici. Un filtro fail2ban richiede log specifici degli errori e test che dimostrino che gli accessi riusciti non vengano bloccati.

I log del core sono una registrazione parziale. PrestaShop 1.6, 1.7.8 e 8.2 registrano le connessioni riuscite al back office con dipendente e IP di origine. Rilevamento degli accessi falliti, analisi della posizione e invio degli avvisi richiedono controlli propri. Conserva insieme log di proxy, autenticazione e applicazione con orari sincronizzati.

Le notifiche personalizzate di accesso devono usare l'integrazione corretta: le versioni legacy compatibili espongono actionAdminLoginControllerLoginAfter; PrestaShop 9 usa eventi di autenticazione Symfony come LoginSuccessEvent. Un avviso email funzionante richiede anche listener registrati, template reali tradotti, un percorso dei template, consegna riuscita e gestione degli errori.

Permessi dei file, identità dell'hosting ed errori di cache

Identifica l'identità del processo PHP prima di cambiare proprietà. I worker PHP-FPM funzionano come utente e gruppo configurati nel pool, che possono differire da Nginx, Apache o un processo master root. Con mod_php, PHP gira nel processo Apache. Con hosting basato su account o suPHP, può girare come il tuo utente hosting.

Per codice applicativo ordinario leggibile, cartelle 755 e file 644 sono modalità iniziali comuni. Il permesso di esecuzione sulle cartelle consente l'attraversamento. Proprietario, gruppo e ACL determinano chi può scrivere. Rendere l'utente PHP proprietario di ogni file di codice permette anche a PHP compromesso di riscriverli. Preferisci codice di proprietà dell'utente di distribuzione e accesso in scrittura durante l'esecuzione limitato dove la procedura di manutenzione lo supporta.

Mantieni app/config/parameters.php leggibile da PHP su PrestaShop 1.7, 8 e 9. La versione legacy 1.6 usa config/settings.inc.php. Una modalità 400 generalizzata può rompere il negozio se PHP non è il proprietario. Non applicare 777 per risolvere un errore di scrittura. PHP vulnerabile può comunque scrivere in una cartella 755 di cui è proprietario.

Correggi un errore di scrittura della cache dopo una migrazione

1. Leggi il percorso esatto dell'errore ed esamina proprietario, gruppo, modalità e permessi di attraversamento delle cartelle superiori.
2. Controlla il worker effettivo PHP-FPM e la configurazione del pool.
3. Concedi all'identità PHP necessaria accesso in lettura, scrittura e attraversamento usando proprietà, gruppo attendibile o ACL.
4. Solo dopo aver corretto l'accesso, rimuovi i contenuti generati della cache nell'ambiente interessato e preriscaldala come utente di esecuzione previsto.
5. Controlla spazio disco, inode, mount in sola lettura, SELinux/AppArmor, percorsi chroot e umask di distribuzione se l'accesso fallisce ancora.

Questo esempio presuppone che tu abbia confermato che il worker PHP gira come www-data e debba possedere questa cache. Usa privilegi elevati per tutte le modifiche delle modalità e modifica separatamente file e cartelle.

sudo chown -R www-data:www-data /var/www/html/var/cache
sudo find /var/www/html/var/cache -type d -exec chmod 750 {} +
sudo find /var/www/html/var/cache -type f -exec chmod 640 {} +

I percorsi scrivibili moderni includono var/cache/, log, img/, upload/ e download/. Installazione di moduli, cambi di tema, traduzioni e aggiornamenti richiedono ulteriore accesso temporaneo in scrittura. Le cache Smarty legacy 1.6 possono trovarsi sotto cache/smarty/. Mantieni separati i permessi dell'updater da quelli del normale front office.

In Docker, confronta UID/GID numerici dentro e fuori il container. I bind mount mantengono la proprietà dell'host. Anche i volumi nominati richiedono inizializzazione e proprietà adeguate; non concedono automaticamente accesso a PHP. Evita un chown ricorrente dell'intero albero come sostituto di un modello di identità ragionato.

Per errori di caricamento, controlla anche i limiti PHP di upload. Per una pagina vuota dopo chmod, controlla attraversamento delle cartelle e log PHP. Rivedi permessi del client SFTP e umask se i caricamenti continuano a cambiare le modalità.

Proteggi configurazione, caricamenti e ambiente PHP

Disattiva l'output di debug in produzione. Imposta _PS_MODE_DEV_ a false in config/defines.inc.php e controlla il comando pertinente Parametri avanzati > Prestazioni > Modalità debug. Registra gli errori in una destinazione protetta. Esamina le impostazioni effettive della SAPI web anziché affidarti a PHP CLI. Una base minima comprende display_errors=Off, log_errors=On, expose_php=Off e allow_url_include=Off.

Disabilitare funzioni di processo come exec, system, shell_exec, passthru, popen e proc_open può limitare alcuni payload ma interrompere attività legittime. I pool PHP-FPM possono impostare php_admin_value[disable_functions] oltre a php.ini. Riavvia il servizio corretto, verifica l'ambiente web e prova elaborazione immagini, importazioni e attività PDF. Questo non impedisce a PHP di leggere dati scrivibili o usare credenziali del database.

open_basedir può limitare i percorsi ma richiede tutti i percorsi temporanei e applicativi legittimi. Consideralo una restrizione aggiuntiva, non una sandbox. Non esporre permanentemente un file phpinfo o di prova della shell.

Blocca i percorsi HTTP sensibili

Disattiva gli elenchi delle cartelle. Nega l'accesso pubblico a configurazione, log, backup, dump SQL, metadati del repository e manifest delle dipendenze. Tieni i backup fuori dalla radice web. Un file PHP di parametri eseguito correttamente non stampa l'array restituito, ma l'esposizione del sorgente o di una copia di backup può rivelare credenziali.

Conserva i percorsi necessari dei certificati /.well-known/ quando limiti i file nascosti. Non negare alla cieca ogni file PHP dei moduli: callback, attività cron e vecchi endpoint AJAX possono dipenderne.

Impedisci agli script caricati di raggiungere PHP

Copri img/, upload/ e download/, incluse estensioni eseguibili alternative e nomi con più estensioni. Esamina la configurazione effettiva del gestore PHP. Questo esempio di virtual host Apache 2.4 nega i nomi eseguibili comuni in questi percorsi:

<DirectoryMatch "/var/www/html/(img|upload|download)(/|$)">
    <FilesMatch "(?i)\.(php[0-9]?|phtml|phar)(\.|$)">
        Require all denied
    </FilesMatch>
</DirectoryMatch>

DirectoryMatch va nella configurazione server o del virtual host. php_admin_flag engine off è specifico di mod_php e non va copiato senza condizioni nelle configurazioni PHP-FPM. Con PHP-FPM, escludi questi percorsi anche dall'esecuzione FastCGI.

Su Nginx, inserisci una location di rifiuto per i nomi eseguibili prima di una location PHP regex generale, adattala all'eventuale sottocartella del negozio ed esamina tutte le location dei gestori. Ad esempio:

location ~* ^/(img|upload|download)/.*\.(php[0-9]?|phtml|phar)(\.|$) {
    return 403;
}
autoindex off;

Convalida la configurazione del server, poi verifica nomi di file bloccati e immagini normali, caricamenti dei clienti, download e callback di pagamento. Adatta le regole a ogni estensione che il server esegue realmente.

HTTPS, header di sicurezza e CSP

Installa e rinnova un certificato valido, abilita SSL e SSL su tutte le pagine in Parametri negozio > Generale nelle versioni moderne, poi verifica reindirizzamenti HTTP, checkout e contenuti misti. In 1.6, le impostazioni Generale sono sotto Preferenze. I browser bloccano contenuti misti attivi come script e possono aggiornare i media misti a HTTPS. Usa console e pannello Network del browser per trovarli.

Reindirizza all'host attendibile configurato. Considera la terminazione TLS su un proxy per evitare cicli. Aggiungi HSTS solo dopo che HTTPS funziona in modo affidabile; usa includeSubDomains solo quando ogni sottodominio interessato supporta HTTPS.

Rivedi X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, restrizioni ai frame e una Permissions-Policy adatta. Verifica pagamenti incorporati e altre integrazioni prima di applicare restrizioni ai frame.

Distribuisci una Content Security Policy per fasi

default-src fornisce valori alternativi. script-src controlla gli script; style-src, img-src e font-src controllano altre risorse; connect-src controlla le connessioni degli script. frame-src controlla i frame incorporati, mentre frame-ancestors controlla chi può incorporare la tua pagina. form-action limita le destinazioni di invio dei moduli. Valuta object-src 'none' per bloccare contenuti object ed embed e base-uri 'self' per limitare gli URL di base, dopo aver provato le integrazioni. Imposta esplicitamente base-uri, form-action e frame-ancestors: non usano default-src come alternativa.

1. Inizia con Content-Security-Policy-Report-Only.
2. Esamina la diagnostica del browser nei flussi di prodotto, carrello, account, contatto, checkout, reindirizzamento e 3-D Secure.
3. Per raccogliere i report, predisponi un servizio ricevente, configura Reporting-Endpoints con report-to e un ripiego report-uri appropriato, poi dimostra che arriva una violazione di prova deliberata.
4. Crea un elenco di origini consentite dai requisiti reali. Rimuovi concessioni ampie https:, 'unsafe-inline' e 'unsafe-eval' dove il supporto compatibile di nonce/hash e template lo consente.
5. Passa all'applicazione vincolante dopo i test e continua a monitorare i report.

Un header report-only non blocca nulla. Senza un ricevitore funzionante, un log server vuoto non dice nulla sulle violazioni. Non fidarti automaticamente delle origini segnalate e non aggiungerle automaticamente all'elenco consentito. Le direttive di reporting sono definite da CSP Level 3.

Una politica che consente 'self' può comunque consentire uno script locale infetto o un relay della stessa origine. Restano necessari controlli di integrità degli script protetti indipendentemente, monitoraggio server e codice aggiornato con patch.

Moduli, accesso al database e punti di ingresso pubblici

Installa moduli da fonti con responsabili identificabili. Esamina manutentori, registri delle modifiche, correzioni di sicurezza e integrità dei pacchetti. Pacchetti non attendibili o modificati possono contenere malware. Una scheda su un marketplace affidabile non prova che il codice sia privo di vulnerabilità.

Disattivare un modulo blocca normalmente le sue route standard ModuleFrontController. Gli script PHP autonomi possono restare eseguibili. Prima di disinstallare software inutilizzato, conserva i dati commerciali e controlla dipendenze, callback e attività pianificate; poi rimuovine i file.

La revisione del codice deve seguire i dati delle richieste attraverso autorizzazione, convalida dei tipi, SQL, scritture di file ed escaping dell'output. eval o payload eseguibili decodificati richiedono attenzione. file_get_contents recupera byte senza eseguirli, quindi esamina destinazione e uso successivo. L'esecuzione di asserzioni come stringhe è stata rimossa in PHP 8. La conversione a intero e pSQL() gestiscono specifici input SQL; non costituiscono una revisione completa della sicurezza.

Usa un account database dedicato limitato al database del negozio, non un account amministratore del database. Concedi i privilegi necessari alle operazioni effettive di esecuzione e manutenzione. Evita privilegi globali, FILE o amministrativi non necessari. Limita l'accesso di rete al database e usa una connessione privata se è remoto.

Proteggi o rimuovi gli strumenti pubblici di amministrazione del database. Preferisci un percorso privato autenticato o un tunnel SSH e disattiva accessi web root/con password vuota. Un prefisso diverso delle tabelle non corregge una SQL injection.

Elimina la cartella install dopo l’installazione e controlla che non ricompaia dopo una migrazione o un ripristino: un installer raggiungibile permette a chiunque di rilanciare l’installazione e prendere il controllo del negozio. Ad aprile 2026 Sansec ha trovato oltre 200 negozi PrestaShop con l’installer esposto.

Accesso Webservice, partner logistici e revoca degli accessi

In Parametri avanzati > Webservice, disattiva l'API se inutilizzata. Altrimenti emetti una chiave separata per integrazione, limita risorse e metodi, richiedi HTTPS, conserva i segreti in sicurezza e revoca le chiavi inutilizzate. Rivedi separatamente client e ambiti Admin API dove distribuiti.

Costruisci l'elenco di accessi di un 3PL dalle sue richieste effettive. Gli ordini contengono ID di indirizzo, quindi la spedizione può richiedere dati di indirizzi, paesi, stati, corrieri e contatti oltre a ordini e dettagli d'ordine. Concedi solo ciò che il flusso richiede.

I permessi delle risorse non sono isolamento per campo o per ordine. I dettagli d'ordine possono rivelare campi del costo d'acquisto. Un elenco di visualizzazione scelto dal client non è un confine di accesso. Se un partner non deve vedere costi o ordini estranei, esponi un endpoint filtrato controllato dal server o un'esportazione.

Aggiornamenti del tracciamento e cambi di stato dell'ordine usano percorsi separati. Creare una risorsa order_histories cambia lo stato; aggiungi sendemail=1 per richiedere la sua email di stato configurata. Lo stato deve anche avere l'email abilitata e un template adatto. Aggiornare una risorsa order_carriers cambia il tracciamento; la sua opzione separata sendemail=1 richiede il messaggio di transito, che necessita anche di un URL di tracciamento del corriere. Entrambe le opzioni hanno come valore predefinito nessuna email. Aggiorna il tracciamento prima di richiedere il messaggio corrispondente e deduplica i tentativi ripetuti.

1. Disattiva immediatamente l'account dipendente della persona uscente al termine dell'accesso.
2. Revoca le sue chiavi individuali Webservice, client API e accessi a hosting, SFTP, SSH, email e terze parti.
3. Invalida le sessioni e ruota i segreti condivisi che conosceva.
4. Conserva l'attribuzione utile di ordini e audit.
5. Rivedi attività pianificate, responsabilità e contatti di recupero.

Un Profilo è un ruolo di permessi riutilizzabile, non un account di accesso con un'opzione di attivazione. Modificare o eliminare un Profilo condiviso può incidere su altri dipendenti. Consulta la guida Webservice per i concetti API.

Esempio pratico: collegamento a un magazzino

Supponi che un magazzino richieda ordini pagati e debba restituire il tracking, ma non debba ricevere i costi d'acquisto. Parti da un ordine di prova e dall'elenco effettivo delle richieste del magazzino. Se i permessi standard sulle risorse espongono campi fuori dall'accordo, applica il filtro nell'integrazione controllata dal tuo server anziché fidarti dei campi di visualizzazione richiesti dal magazzino.

Prova il collegamento su staging con la posta in uscita intercettata da una casella di prova. Recupera i dati concordati di ordine e indirizzo, poi tenta di recuperare costi d'acquisto e un ordine estraneo tramite l'accesso del partner; nessun tentativo deve divulgare dati esclusi. Aggiorna il tracking prima di richiedere le azioni concordate di stato ed email. Ripeti lo stesso evento del magazzino e conferma che la gestione dei nuovi tentativi impedisca voci di storico e messaggi duplicati. Revoca la chiave di prova del magazzino e conferma che la richiesta successiva fallisca; dimostra che puoi interrompere l'integrazione oltre che avviarla.

Verifica l'uscita di un dipendente oltre alla rimozione del nome

Dopo i passaggi di uscita sopra, verifica che sessione esistente e nuovo accesso del dipendente uscente siano respinti e che le credenziali API revocate falliscano. Conferma che il personale rimasto possa continuare a lavorare. Se una vecchia sessione resta utilizzabile, indaga i controlli delle sessioni della versione o del livello di accesso anziché presumere che la disattivazione del dipendente l'abbia invalidata. Controlla che email di recupero, credenziali delle attività pianificate e destinazioni dei backup appartengano ora a un responsabile.

Assumi e delega con accessi controllati

Identifica il collo di bottiglia prima di coinvolgere altre persone. Esamina da quanto tempo sono aperte le conversazioni di assistenza, ritardi tra pagamento e spedizione, errori di scorte, richieste perse e lavoro che si ferma quando ti assenti. Misura la prima risposta dai timestamp dei messaggi o da un report help desk; l'elenco core non è una dashboard completa dei tempi di risposta.

Ricavi o movimenti bancari da soli non danno il margine netto per ordine. Usa il calcolo seguente per confrontare il costo completo dell'aiuto con il contributo aggiuntivo che il tempo liberato può produrre realisticamente e considera la domanda stagionale.

Per inserire una persona, crea il ruolo in Team > Profili, configura i Permessi, poi crea il Dipendente con quel profilo e solo l'accesso ai negozi pertinenti. Prova il ruolo accedendo come quella persona, inclusi URL diretti e azioni di moduli di terze parti. Nascondere un menu non basta come prova di autorizzazione. Limita rigorosamente installazione dei moduli, SQL Manager e gestione dei dipendenti. Il permesso di installare un modulo consente di introdurre codice PHP lato server, quindi trattalo come un privilegio di rilascio.

Documenta flusso degli stati d'ordine, regole di reso/rimborso, procedure delle scorte e passaggi di escalation dell'assistenza. I Messaggi d'ordine predefiniti si selezionano dalla pagina di un ordine. Le conversazioni del Servizio clienti usano comportamenti propri per firma e risposta predefinita; un catalogo condiviso di risposte richiede un'integrazione helpdesk adatta.

Mantieni strategia prodotto, scelta dei fornitori, direzione del marchio e politica clienti sotto una responsabilità chiara. Esternalizza attività definite quando standard qualitativo, frequenza, contesto richiesto e costo lo giustificano. Confronta costi di stoccaggio, ricezione, prelievo/imballaggio, spedizione, resi e minimi di un 3PL con i tuoi.

Fornisci ai fornitori un incarico scritto, esempi di accettazione, calendario di comunicazione e chiara titolarità di materiali/credenziali. Rivedi il lavoro continuativo dei collaboratori quando il coordinamento diventa un collo di bottiglia. Lo status lavorativo dipende dalle regole locali e dal rapporto effettivo, non da una soglia di ore settimanali. Preferisci hook, decorazione dei servizi e punti di estensione supportati del tema prima di affidarti esclusivamente agli override legacy.

Scegli l'aiuto in base al collo di bottiglia

Esegui un calcolo di assunzione con i tuoi dati: stima gli ordini aggiuntivi che la capacità liberata può realisticamente servire, poi moltiplica per il margine di contribuzione per ordine aggiuntivo dopo costo del prodotto, commissioni di pagamento, evasione, resi attesi e altri costi variabili. Confronta quel contributo con stipendi o compensi dei collaboratori, oneri del datore di lavoro, formazione, supervisione e strumenti nello stesso periodo. Se manca una domanda aggiuntiva realistica, manca anche il contributo alla crescita; la giustificazione si basa allora su qualità del servizio, continuità o carico di lavoro anziché su ricavi presunti.

Per un collaboratore del catalogo, per esempio, fornisci una mappatura CSV concordata e righe di esempio prima di concedere l'accesso all'importazione. Convalida riferimenti dei prodotti, lingua e ambito del negozio su staging, esamina i prodotti modificati, poi approva l'importazione in produzione. Un fotografo può consegnare file nominati per riferimento senza alcun accesso al back office; il risultato di uno specialista non richiede automaticamente accesso al negozio.

Filtraggio del traffico e negozi in attesa di migrazione

Un WAF può bloccare specifiche richieste di exploit, limitare abusi e proteggere route costose come gli URL di ricerca a faccette. Verifica le regole con navigazione, checkout, API e callback dei fornitori. Robots.txt è un suggerimento per i crawler, non un controllo di accesso. Blocchi per paese e IP possono colpire clienti legittimi, soprattutto dietro reti condivise.

Quando un proxy protegge il negozio, limita le porte web dell'origine alle reti proxy attendibili e ai percorsi di gestione necessari. Copri IPv4 e IPv6 e mantieni aggiornati gli elenchi di indirizzi. Record email e vecchi DNS possono rivelare un IP d'origine. Mantieni accessi SSH, email e pannello hosting sotto regole separate.

I campi delle espressioni di limitazione della frequenza Cloudflare variano per piano: Free offre campi basati sul percorso, Pro aggiunge il confronto della query e Business aggiunge campi di IP sorgente e user-agent. Il conteggio per IP è una capacità separata. Advanced Rate Limiting è un'offerta Enterprise separata. Controlla la disponibilità attuale prima di progettare una regola contro le raffiche di richieste che tenga conto della query.

Il CAPTCHA può ridurre gli abusi nel front office, ma richiede prove di accessibilità e di errore. reCAPTCHA & hCaptcha Protection copre i moduli cliente supportati; segui la guida del modulo per la configurazione.

Customer Extra Info (IP Ban) fornisce informazioni sui visitatori e blocco IP; segui la guida del modulo per configurare l'ambito applicabile.

Usa controlli compensativi durante la migrazione

Identifica componente vulnerabile e avviso esatti. Una regola di intercettazione WAF esterna è una patch virtuale; modificare il sorgente è una patch diretta o un backport. Traccia e verifica ogni misura temporanea e imposta una data di rimozione collegata al piano di aggiornamento.

Per la catena d'attacco legacy della cache MySQL di Smarty, controlla la versione interessata e la correzione upstream. In 1.7.8, _PS_SMARTY_CACHING_TYPE_ è una costante PHP e controlla il caricamento della risorsa cache MySQL. Non è un selettore della pagina Prestazioni. Verifica la risorsa cache effettiva durante l'esecuzione dopo la correzione.

Esamina singolarmente gli endpoint autonomi abbandonati anziché bloccare tutto il PHP dei moduli. L'immutabilità dei file è un controllo amministrativo facoltativo per file censiti singolarmente; alcuni file di configurazione vengono legittimamente modificati da PrestaShop. Documenta come sbloccarli per la manutenzione e ribloccarli dopo.

Rendi verificabile il contenimento temporaneo

Per ogni regola temporanea o correzione riportata a una versione precedente, registra componente interessato e versione installata, avviso o prove nei log, richiesta o percorso di codice preciso coperto, responsabile, procedura di annullamento e dipendenza della migrazione che lo eliminerà. Un blocco generico di parole sospette può ignorare input codificati e respingere ricerche legittime; prova il percorso di attacco confermato insieme alle richieste normali.

Per esempio, un modulo di ricerca legacy può richiedere sia una correzione mirata per una query vulnerabile sia una regola di traffico contro richieste onerose dei crawler. Questi controlli affrontano problemi diversi. Dimostra che la richiesta bloccata viene negata, i filtri legittimi funzionano ancora e l'origine non può aggirare il proxy, poi conserva i risultati con il piano di migrazione. Esamina gli eventi WAF osservati prima di applicare i blocchi, affinché callback di pagamento, crawler utili e traffico cliente siano rappresentati nella decisione.

Monitoraggio e autocontrollo pratico

Monitora PHP, JavaScript e template nuovi e modificati rispetto a una base di distribuzione attendibile. Proteggi la base separatamente, rivedi le esclusioni e pianifica scansioni effettive e consegna degli avvisi se serve rilevamento non presidiato. Una scansione manuale è un confronto in un dato momento.

Confronta il core con la stessa versione pulita e i file dei moduli con pacchetti attendibili. Esamina account dipendente inspiegabili, impostazioni di pagamento alterate, campi checkout sconosciuti e script inattesi. I cambiamenti ai file possono anche essere distribuzioni legittime; indaga invece di eliminare automaticamente le corrispondenze.

Per una revisione dei dipendenti in sola lettura, sostituisci il prefisso delle tabelle se necessario:

SELECT id_employee, email, id_profile, active, last_connection_date
FROM ps_employee
ORDER BY id_employee DESC;

La tabella standard dei dipendenti non ha date_add. Un ID crescente può aiutare a rivedere account sconosciuti ma non è un timestamp di creazione. last_connection_date non è un campo dell'età dell'account.

Dalla radice del negozio, queste ricerche in sola lettura identificano file da esaminare:

find img upload download -type f -iname '*.php*' -print
find img upload download -type f \( -iname '*.phtml*' -o -iname '*.phar*' \) -print
find . -type f -name '*.php' -mtime -14 -print
find . -type f -name '*.js' -mtime -14 -print
find . -type f -name '*.php' -exec awk 'length($0)>5000 {print FILENAME ":" FNR}' {} +

Righe lunghe e stringhe codificate possono essere legittime. Correla mtime, ctime, timestamp di nascita supportati, log e istantanee. Ctime è l'ultima modifica dello stato dell'inode, non la creazione iniziale del file; modifiche a proprietà e modalità possono aggiornarlo.

Monitora contenuto della homepage, pagine rappresentative del catalogo e disponibilità del checkout, non solo HTTP 200. Controlla indipendentemente il rinnovo del certificato. Conferma che il piano di monitoraggio scelto includa avvisi su certificato e tempi di risposta, poi verifica la consegna a un canale presidiato.

Un autocontrollo deve coprire versioni software, aggiornamenti dei moduli, dipendenti, confronti dei file, restrizioni sull'origine e un backup ripristinato. Un profilo dipendente in sola lettura non rende automaticamente sicuro per un revisore ogni endpoint di configurazione di terze parti; concorda esplicitamente accesso richiesto e gestione dei dati. Usa un account temporaneo per una verifica esterna, fornisci dove possibile accesso in lettura a file e log, poi rimuovi l'account al termine del lavoro concordato. La guida alla preparazione dell'audit ti aiuta a preparare questo passaggio.

Per una prima verifica locale, Security Scan segnala gratuitamente risultati con priorità e passaggi manuali di correzione. L'esame è in sola lettura e mantiene i risultati nel negozio; non blocca traffico, modifica file o cambia impostazioni. Scansioni pianificate e avvisi per criticità supportano il seguito, ma un punteggio non può dimostrare l'assenza di un'infezione.

Trasforma i risultati nell'azione successiva

Conserva ogni risultato irrisolto con posizione, prove, responsabile e azione successiva. Un autocontrollo senza problemi risponde solo ai controlli effettivamente eseguiti. Inoltra i risultati che non sai spiegare e ripeti i controlli pertinenti dopo aggiornamenti, cambi di tema, nuove integrazioni o passaggi degli accessi.

Backup e risposta agli incidenti

Esegui il backup di database e file corrispondenti con una frequenza adatta alla tua tolleranza alla perdita di ordini. Conserva più punti di ripristino, cifra gli archivi sensibili e mantieni una copia esterna al server con credenziali separate. Definisci la conservazione dai requisiti di recupero e aziendali anziché da un numero universale di giorni.

Usa credenziali database protette e uno strumento di backup che controlli gli errori. Nei comandi crontab inline, i segni percentuali richiedono un singolo escape; inserire il flusso di backup in uno script evita questa trappola. Prova un ripristino su un negozio isolato, inclusi accesso clienti, immagini, ordini e configurazione. Consulta la guida ai backup.

Se sospetti una compromissione

1. Isola il negozio tramite un livello server o proxy attendibile. Impedisci ulteriori acquisti o esposizione di dati mantenendo l'accesso per i responsabili della risposta.
2. Conserva le prove dell'incidente: database, file, log pertinenti e timestamp. Archivia le copie in sicurezza prima di una pulizia distruttiva.
3. Identifica punto d'ingresso e persistenza, inclusi account dipendente, attività pianificate e contenuti iniettati nel database.
4. Da un dispositivo e ambiente puliti, revoca le sessioni e ruota le credenziali esposte di hosting, SSH, SFTP, database, dipendenti, email e pagamenti/API. Coordina le modifiche di configurazione per consentire il recupero.
5. Ricostruisci da pacchetti software attendibili e ripristina dati puliti, poi correggi il punto d'ingresso. Non trasferire un tema compromesso, un albero di immagini o un database senza esaminarlo.
6. Verifica checkout, pagamenti, rimborsi, email e integrazioni prima della riapertura. Monitora attentamente eventuali ricorrenze.

Se usi Apache per restituire lo stato di manutenzione, configura ErrorDocument 503 separatamente. Una riscrittura con R=503 non restituisce di per sé la destinazione della riscrittura come pagina di manutenzione.

Avvisa host, fornitore di pagamento e responsabili della sicurezza secondo necessità. Ai sensi dell'articolo 33 GDPR, notifica la violazione all'autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore da quando vieni a conoscenza della violazione, salvo che il rischio per le persone sia improbabile. L'articolo 34 richiede generalmente di informare gli interessati senza ingiustificato ritardo quando è probabile un rischio elevato, fatte salve le sue eccezioni. Usa le indicazioni EDPB sulle violazioni e la tua procedura di protezione dei dati.

Prima di riaprire, conferma che il debug sia disattivato, gli strumenti temporanei rimossi, gli endpoint vulnerabili corretti o rimossi, credenziali e accessi dei dipendenti controllati, i backup ripristinabili e gli avvisi recapitati al responsabile.

Concorda in anticipo le decisioni di recupero

Scrivi chi può autorizzare il contenimento, contattare hosting e fornitore di pagamento, recuperare backup protetti e approvare la riapertura. Registra la tolleranza alla perdita di ordini e l'interruzione accettabile, poi misura un ripristino isolato rispetto a questi limiti. I backup possono contenere gli stessi file dannosi o contenuti iniettati nel database del negozio in produzione, quindi la scelta del punto di ripristino richiede prove di quando è iniziata l'intrusione.

Esamina quali dati personali conservano negozio, moduli, esportazioni e log. Rimuovi copie inutili tramite una procedura concordata di conservazione e limita le restanti. Raccogliere dati aggiuntivi senza un'esigenza aziendale aumenta ciò che un attaccante può ottenere; copiarli su staging o in un archivio di incidente richiede anch'esso accessi controllati.

Cosa chiedere al tuo sviluppatore o alla tua agenzia

• Quale componente e versione esatti sono esposti e quali prove collegano la modifica proposta a quell'esposizione?
• Quali controlli si trovano nell'hosting, nel proxy, nel negozio o nel modulo e chi mantiene ciascuno dopo la consegna?
• Quali funzionalità esistenti del tema, percorsi di pagamento, mercati e integrazioni dei partner sono stati provati su staging, incluse azioni negate e recupero?
• Qual è la procedura di passaggio e ritorno e come si riconciliano ordini o pagamenti ricevuti durante una migrazione?
• Dove sono la base di riferimento del rilascio, i risultati del ripristino e le prove di consegna degli avvisi? Chi interviene quando un controllo fallisce?
• Quali regole temporanee, credenziali e strumenti vanno rimossi e quali interventi correttivi restano fuori dalla valutazione concordata?

Domande dei commercianti

L'hosting gestito si occupa della sicurezza del negozio?

Chiedi per iscritto i confini della manutenzione. La manutenzione di sistema operativo e server non stabilisce chi aggiorna installazione PrestaShop, tema o moduli. Conferma chi esamina gli avvisi, approva le modifiche al negozio e risponde agli allarmi dell'applicazione secondo il tuo accordo effettivo.

E se il team non può usare IP fissi dell'ufficio?

Valuta un'uscita VPN gestita o un proxy di accesso basato sull'identità con autenticazione individuale. Prova le sedi reali di lavoro del team e il recupero per dispositivo smarrito prima di imporlo. Mantieni un percorso di recupero approvato anziché ampliare l'elenco degli IP consentiti ogni volta che qualcuno viaggia.

Devo installare subito uno scanner se sospetto una violazione?

Concorda prima il metodo di esame con chi risponde all'incidente. Installare software modifica i file e può alterare prove utili o la base di riferimento che stai confrontando. Conserva lo stato interessato e organizza l'ispezione da un ambiente affidabile prima di aggiungere strumenti a un'installazione sospetta.

Come invio log o credenziali a chi mi aiuta?

Concorda un canale di trasferimento protetto e fornisci solo quanto serve all'indagine. Oscura dati personali estranei e segreti da screenshot ordinari e allegati dei ticket; se un log originale serve come prova, conservalo separatamente con accesso controllato. Usa accessi individuali temporanei anziché incollare una password condivisa del titolare in un ticket.

Le regole temporanee possono restare dopo la migrazione?

Rivedi ogni regola rispetto all'esposizione effettiva del negozio migrato. Rimuovi eccezioni obsolete e ritira una regola compensativa solo dopo aver dimostrato che il percorso vulnerabile sottostante è corretto o eliminato. Mantieni difese e monitoraggio utili dove hanno ancora uno scopo documentato.