Checklist di sicurezza WordPress: cosa controllare prima e dopo la pubblicazione

WordPress alimenta una larga fetta del web, e per questo è il bersaglio predefinito degli attacchi automatizzati. I bot non si chiedono se il tuo sito sia importante: scansionano ogni dominio nuovo alla ricerca di plugin vulnerabili noti, login deboli e file esposti, di solito entro poche ore dalla messa online. La maggior parte dei siti WordPress compromessi non era un bersaglio scelto: era semplicemente non aggiornata o configurata male.

Ecco cosa fare prima di pubblicare, e cosa continuare a fare dopo.

Prima di andare online

1. Parti da un’installazione pulita e minimale

Installa WordPress da wordpress.org, mai da pacchetti “nulled” (pirata) di temi o plugin: sono la prima fonte di backdoor.
Elimina quello che non usi: plugin di default (Hello Dolly), temi inutilizzati (tienine uno di default come fallback), contenuti di esempio.
Ogni plugin è superficie d’attacco. Pochi plugin ben mantenuti battono tanti plugin. Controlla che ognuno abbia aggiornamenti recenti, una base di installazioni decente e nessuna vulnerabilità aperta e non corretta.

2. Tieni tutto aggiornato

La maggior parte delle compromissioni WordPress arriva da plugin e temi, non dal core. Abilita gli aggiornamenti automatici per le release minori del core (già attivi di default) e per i plugin di cui ti fidi. Controlla anche la versione di PHP: le versioni non più supportate non ricevono correzioni di sicurezza.

3. Blinda l’autenticazione

Non usare admin come username e usa una password lunga e unica, da un password manager.
Abilita l’autenticazione a due fattori per ogni amministratore ed editor. Per capire perché le passkey sono un’opzione più forte, leggi WebAuthn e passkey.
Limita i tentativi di login e valuta di cambiare o proteggere /wp-login.php.
Dai a ogni persona un account con il minimo privilegio necessario (Editor, non Amministratore).
Disabilita l’editor di file integrato in wp-config.php, così una sessione admin rubata non può scrivere PHP dalla dashboard:

define( 'DISALLOW_FILE_EDIT', true );

4. Migliora `wp-config.php` e i permessi dei file

// Forza admin e login su HTTPS
define( 'FORCE_SSL_ADMIN', true );

// Non mostrare mai errori ai visitatori
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

Usa chiavi di autenticazione e salt unici (generali dall’API ufficiale).
Sposta wp-config.php sopra la web root se l’hosting lo permette, oppure blocca l’accesso diretto.
Permessi tipici: directory 755, file 644, wp-config.php 600 o 640. L’utente del web server non dovrebbe possedere i file del core, a meno che ti servano gli aggiornamenti automatici dalla dashboard.
Usa un prefisso delle tabelle diverso da quello di default e un utente database dedicato con solo i privilegi che servono a WordPress, non root.

5. Forza HTTPS e aggiungi gli header di sicurezza

Ottieni un certificato (Let’s Encrypt è gratuito), reindirizza HTTP a HTTPS e abilita HSTS solo dopo esserti assicurato che tutto funzioni in HTTPS. Poi aggiungi gli header di risposta a livello di web server:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN
Permissions-Policy: camera=(), microphone=(), geolocation=()

La Content Security Policy è l’header più potente ma anche il più difficile su WordPress, perché temi e plugin iniettano script inline. Parti in modalità report-only. Vedi la guida alla CSP e il seguito su nonce e strict-dynamic.

6. Riduci ciò che il sito rivela ed espone

Blocca XML-RPC (/xmlrpc.php) se non lo usi. Permette di amplificare i brute force tramite system.multicall.
Disabilita il directory listing.
Blocca l’esecuzione di PHP in wp-content/uploads/, dove finirebbe una webshell caricata.
Assicurati che backup, .git, .env, *.sql, *.zip e debug.log non siano raggiungibili dal web: motori di ricerca e bot li cercano.
Controlla l’endpoint utenti della REST API (/wp-json/wp/v2/users): può far trapelare gli username. Limitalo se non ti serve pubblico.

7. Configura backup che hai davvero ripristinato

Un backup mai testato è una speranza, non un backup. Conserva file + database, fuori dal server, con più punti di retention (così un ransomware o una compromissione silenziosa non sovrascrive l’unica copia buona). Fai un ripristino di prova prima del lancio.

8. Aggiungi un livello di firewall

Un web application firewall (Cloudflare, Sucuri o un plugin come Wordfence) blocca richieste note come malevole, limita i tentativi di login e nasconde l’IP di origine. Non sostituisce gli aggiornamenti, ma ti fa guadagnare tempo tra la divulgazione di una vulnerabilità e la tua patch.

Checklist pre-lancio

Dopo la pubblicazione

La sicurezza è una routine, non un’attività di lancio.

1. Verifica dall’esterno

Scansiona il sito online: controlla gli header con securityheaders.com, il TLS con SSL Labs, e prova tu stesso a richiedere /xmlrpc.php, /.git/config, /wp-content/debug.log e /wp-content/uploads/. Tutto ciò che non è 403/404 va controllato.

2. Monitora aggiornamenti e vulnerabilità

Iscriviti a un feed di vulnerabilità per i plugin WordPress (Patchstack, WPScan/Wordfence intelligence). Un plugin può essere sicuro il lunedì e avere un exploit critico il venerdì. Controlla la lista degli aggiornamenti almeno una volta a settimana e applica in fretta quelli di sicurezza, testando prima in staging quelli più grossi.

3. Registra e ricevi alert

Tieni un activity log (chi ha fatto login, chi ha cambiato cosa, quali plugin sono stati installati).
Ricevi alert su nuovi utenti admin, file del core modificati e picchi di login falliti.
Usa controlli di integrità dei file: wp core verify-checksums e wp plugin verify-checksums --all (WP-CLI) confrontano i file con le release ufficiali.

wp core verify-checksums
wp plugin verify-checksums --all

4. Monitoraggio uptime e malware

Il monitoraggio dell’uptime rileva defacement o downtime. Una scansione malware periodica (lato server, perché il malware può ingannare gli scanner a plugin) individua il codice iniettato. Tieni d’occhio anche il report Problemi di sicurezza di Google Search Console: Google spesso segnala un sito hackerato prima che te ne accorga.

5. Testa di nuovo i backup

Ripristina su una copia di staging ogni qualche mese. Verifica che la pianificazione giri ancora e che lo spazio non sia esaurito.

6. Rivedi periodicamente utenti e plugin

Rimuovi gli account di chi se n’è andato, ruota le chiavi API ed elimina i plugin che non usi più. Ogni plugin rimosso è una cosa in meno da aggiornare.

7. Prepara un piano per gli incidenti

Se il sito è compromesso: mettilo in manutenzione, ripristina da un backup pulito (non limitarti a “pulire” i file a mano), cambia tutte le password (WordPress, database, hosting, FTP/SSH) e i salt, aggiorna tutto, poi scopri come sono entrati, altrimenti succederà di nuovo.

Routine post-lancio

Ogni settimana: applica gli aggiornamenti, controlla il log di sicurezza/attività
Ogni mese: rivedi utenti e plugin, controlla i problemi di sicurezza in Search Console
Ogni trimestre: prova un ripristino del backup, ripeti le scansioni di header e TLS
Sempre: un canale di alert che una persona legge davvero

WordPress nei container

Se distribuisci con Docker ottieni un isolamento utile (filesystem in sola lettura, nessuno strumento shell nell’immagine, segreti tramite variabili d’ambiente). Non elimina la necessità di nulla di quanto sopra, perché il codice vulnerabile resta dentro il container. Vedi WPDockerize per uno stack rapido.

Conclusione

La maggior parte degli incidenti WordPress nasce da un breve elenco di cause: plugin non aggiornati, password deboli o riutilizzate, file esposti e backup assenti. La checklist qui sopra punta proprio a quelle. Falla una volta bene prima del lancio, poi mantieni una piccola routine noiosa.

Riferimenti: