Checklist di sicurezza WordPress per aziende UE (2026)

Questa checklist di sicurezza WordPress raccoglie le 25 misure che consigliamo per qualsiasi sito aziendale nell'UE, suddivise in sei aree: hosting, software WordPress, account, monitoraggio, backup e documentazione. Conviene procedere dall'alto verso il basso: i primi tre gruppi fermano la maggior parte degli attacchi, gli ultimi tre servono ad accorgersi di un incidente, a rimettere in piedi il sito e a dimostrare che cosa è stato fatto.

Ogni voce riporta il motivo in una riga e, dove serve, il link a una guida di approfondimento. Nessuna checklist rende un sito «sicuro al 100%», ma questa garantisce un livello di protezione che si può spiegare a un cliente, a un revisore o a un'autorità di controllo.

Perché la rapidità è decisiva: il fornitore di sicurezza Patchstack ha contato 11.334 nuove vulnerabilità nell'ecosistema WordPress nel 2025, il 91% delle quali nei plugin, e ha rilevato che circa la metà di quelle ad alto impatto è stata sfruttata entro 24 ore (Patchstack, State of WordPress Security in 2026, report di un fornitore del settore). Una routine costante vale più di qualsiasi singolo strumento.

Hosting e server

Se il server è debole, nessuna impostazione dentro WordPress può compensarlo del tutto.

• HTTPS su ogni pagina, poi HSTS. HTTPS cifra in transito login, dati dei moduli e ordini, e l'art. 32, par. 1, lett. a) del GDPR cita espressamente la cifratura. HSTS (RFC 6797) va aggiunto solo quando HTTPS funziona ovunque, partendo da un max-age breve: per tutto quel periodo i browser rifiutano le connessioni HTTP in chiaro.
• Una versione di PHP supportata. I rami di PHP arrivati a fine vita non ricevono più correzioni di sicurezza; conviene confrontare la versione in uso con l'elenco ufficiale.
• SFTP o SSH al posto di FTP, e un account isolato per ogni sito. FTP trasmette le password in chiaro e, senza isolamento, un solo sito compromesso può infettare tutti gli altri ospitati sullo stesso account.
• Nessuna esecuzione di PHP nella cartella uploads. Lì dovrebbero trovarsi solo file multimediali; un file PHP in quella cartella è quasi sempre una web shell.

Con Apache 2.4, inserire queste righe in wp-content/uploads/.htaccess:

<FilesMatch "\.(?i:php|phtml|phar)$">
    Require all denied
</FilesMatch>

Con nginx, aggiungere questo blocco all'interno del blocco server, prima del blocco generico location ~ \.php$ (vale la prima location con espressione regolare che corrisponde):

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Prima di ricaricare nginx, verificare la configurazione con nginx -t. Con entrambi i server, controllare poi che le immagini si carichino ancora e che un file .php di prova in uploads restituisca «403 Forbidden».

Core, plugin e temi di WordPress

È nei plugin che si concentra la maggior parte delle vulnerabilità, perciò questo gruppo richiede una routine settimanale. La nostra guida ai plugin WordPress vulnerabili entra nel dettaglio.

• Lasciare attivi gli aggiornamenti automatici di sicurezza del core. Per impostazione predefinita WordPress installa in background le versioni minori, che contengono le correzioni di sicurezza. Verificare che nessuna impostazione o strumento del provider li abbia disattivati.
• Aggiornare plugin e temi nel giro di giorni, non di mesi. Per le vulnerabilità sfruttate più intensamente, Patchstack ha misurato una mediana ponderata di cinque ore prima dello sfruttamento di massa. Gli aggiornamenti automatici, disponibili da WordPress 5.5, riducono questo margine per i plugin a basso rischio.
• Eliminare ciò che non si usa. I file di un plugin disattivato restano sul server e possono ancora essere sfruttati; il comando wp plugin list --status=inactive elenca i candidati.
• Sostituire i plugin abbandonati e non usare mai copie «nulled». Nei dati di Patchstack, il 46% delle vulnerabilità non aveva una correzione al momento della divulgazione. Un plugin abbandonato potrebbe non riceverla mai, e una copia piratata non riceve alcun aggiornamento.
• Disattivare l'editor dei file nella bacheca. define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php rimuove gli editor dei file di temi e plugin: chi ruba un accesso da amministratore non può semplicemente incollare codice in un file del tema.

Account e accessi

Un amministratore può installare plugin, cioè eseguire codice sul server. I ruoli predefiniti (Amministratore, Editore, Autore, Collaboratore, Sottoscrittore) rendono semplice applicare il principio del privilegio minimo.

• Password uniche e autenticazione a due fattori per ogni Amministratore ed Editore. Gli attacchi di credential stuffing provano proprio le password trapelate e riutilizzate. Il core di WordPress non include la 2FA; la nostra guida all'autenticazione a due fattori illustra le opzioni.
• Un account personale per ogni persona, con il ruolo più basso sufficiente. Gli accessi condivisi «dell'agenzia» nascondono chi ha fatto cosa e non si possono revocare in modo pulito.
• Rimuovere gli account non più necessari e le password per le applicazioni inutilizzate. Ex dipendenti e agenzie mantengono l'accesso finché qualcuno non lo elimina; le password per le applicazioni (Application Passwords, presenti da WordPress 5.6) sono elencate nel profilo di ciascun utente.
• Limitare i tentativi di login e disattivare XML-RPC se non serve. XML-RPC è attivo per impostazione predefinita e accetta password al di fuori del normale modulo di accesso. Prima di spegnerlo, verificare che nessun plugin o app ne dipenda ancora.

Monitoraggio e rilevamento

Un termine di notifica di 72 ore si può rispettare solo se ci si accorge della violazione.

• Scansioni pianificate di malware e integrità dei file. Nuovi file PHP negli upload, file del core modificati e codice offuscato sono tracce tipiche di una compromissione. wp core verify-checksums confronta i file del core con i checksum ufficiali di WordPress.org. Si vedano anche i 12 segnali che un sito è stato violato.
• Log delle attività e avvisi per i nuovi amministratori. Gli account amministratore nascosti sono un modo frequente con cui gli aggressori si garantiscono l'accesso. I log aiutano a ricostruire un incidente; poiché contengono indirizzi IP, occorre fissare un periodo di conservazione.
• Avvisi di vulnerabilità per i plugin effettivamente installati. Un database di vulnerabilità, per esempio quello di WPScan o di Patchstack, segnala quando uno dei plugin in uso ha un problema noto.
• Google Search Console e monitoraggio dell'uptime. Search Console segnala i problemi di sicurezza che Google rileva sul sito, come lo spam iniettato; i controlli di uptime intercettano le interruzioni.

Il plugin Security Audit & Compliance di secaudit.eu automatizza diversi di questi controlli (integrità dei file, firme di malware, amministratori nascosti, plugin obsoleti, password deboli e impostazioni di hardening) e collega i risultati all'art. 32 del GDPR e all'art. 21 della NIS2.

Backup e ripristino

L'art. 32, par. 1, lett. c) del GDPR chiede la capacità di ripristinare tempestivamente la disponibilità e l'accesso ai dati personali dopo un incidente. Solo backup collaudati mantengono questa promessa.

• Backup automatici di file e database, almeno giornalieri per i siti attivi. Ordini e invii dei moduli cambiano ogni giorno: un backup vecchio di una settimana li perde.
• Almeno una copia fuori dal server e fuori portata. Un archivio di backup nella web root può scaricarlo chiunque ne indovini il nome, e un backup che il sito stesso può cancellare può cancellarlo anche un aggressore.
• Provare un ripristino almeno due volte l'anno. Un backup mai ripristinato è una speranza, non un piano, e l'art. 32, par. 1, lett. d) chiede di testare regolarmente le misure.
• Un piano di risposta agli incidenti di una pagina. Chi decide, chi chiama il provider, dove si trovano i backup puliti e come notificare un data breach entro 72 ore. Il nostro piano di rimozione del malware copre la bonifica.

Documentazione e conformità

L'art. 5, par. 2, del GDPR impone di poter comprovare le misure adottate. Bastano registrazioni brevi e datate.

• Un inventario di plugin, temi, servizi esterni e accessi. Non si può aggiornare né verificare ciò che non si conosce. Nell'elenco vanno anche le richieste verso terzi, come i Google Fonts caricati dai server di Google.
• Accordi sul trattamento dei dati con il provider di hosting e con l'agenzia. Chiunque tratti dati personali per conto dell'azienda, compresa un'agenzia con accesso da amministratore, deve averne uno ai sensi dell'art. 28 del GDPR.
• Un registro delle violazioni e degli incidenti. L'art. 33, par. 5, impone di documentare ogni violazione dei dati personali, comprese quelle che non è stato necessario notificare.
• Prove datate, riesaminate almeno una volta l'anno. Log degli aggiornamenti, report delle scansioni e test di ripristino dimostrano che le misure funzionano davvero.

Come questa checklist di sicurezza WordPress si collega a GDPR e NIS2

L'art. 32, par. 1, del GDPR richiede misure tecniche e organizzative adeguate, tenendo conto dello stato dell'arte, dei costi di attuazione e del rischio. L'art. 21, par. 2, della direttiva NIS2 elenca dieci misure minime per i soggetti che rientrano nel suo ambito di applicazione.

La NIS2 riguarda soprattutto le medie e grandi imprese dei settori elencati, e i dettagli cambiano da Paese a Paese: va quindi verificata la legge nazionale di recepimento. I fornitori più piccoli sono coinvolti indirettamente, perché i soggetti obbligati devono gestire la sicurezza della catena di approvvigionamento e chiedono prove ai propri fornitori. Approfondimenti nei nostri articoli sull'art. 32 del GDPR e sull'ambito di applicazione della NIS2. Chi vende plugin o temi deve inoltre rispettare gli obblighi del fabbricante previsti dal Cyber Resilience Act.

Domande frequenti

Con quale frequenza conviene ripercorrere questa checklist?

Consigliamo una verifica completa almeno una volta l'anno e dopo ogni cambiamento importante, come il passaggio a un nuovo hosting o a una nuova agenzia.

Completare la checklist rende il sito conforme al GDPR?

Nessuna checklist può farlo da sola. L'art. 32 si basa sul rischio: un e-commerce con account clienti ha bisogno di più protezione di un sito vetrina. La checklist copre la base tecnica; la documentazione spiega perché quella base è adeguata al rischio concreto.

Abbiamo solo un piccolo sito vetrina. Vale anche per noi?

Nella maggior parte dei casi sì. Gli attacchi automatizzati non guardano alle dimensioni dell'azienda, e il GDPR si applica non appena un modulo di contatto raccoglie dati personali.

Questo articolo ha carattere informativo generale e non costituisce consulenza legale.