Hardening WordPress essenziale: 12 mosse che servono davvero

Le checklist di hardening WordPress online tendono a essere lunghissime e spesso copiate. Ne trovi versioni da 30, 50, 80 punti, con consigli che nella pratica non spostano niente o che, applicati a caso, rompono il sito.

Questa è la lista più corta possibile dei controlli che, nei nostri interventi, fanno la differenza tra "sito esposto" e "sito difficile da bucare". Sono dodici punti scelti perché incidono davvero sul rischio. Nessuno di questi è teoria: vengono applicati su siti reali, con clienti veri, ogni settimana.

1. Aggiornamenti regolari di core, plugin e temi

Banale, ma è il punto numero uno per una ragione. La maggior parte delle compromissioni che vediamo sfruttano vulnerabilità note in plugin non aggiornati. Spesso il fix è disponibile da mesi.

La regola pratica è: mai più di 30 giorni di ritardo sulle versioni stabili, salvo problemi di compatibilità noti. Per i siti in manutenzione continuativa programmiamo aggiornamenti settimanali con verifica funzionale post-update.

2. Solo plugin e temi con licenza valida

Un plugin nulled non aggiornato non è più "gratis": è una porta lasciata aperta. Più del 30% dei casi di compromissione che gestiamo in agenzie partono da temi o plugin premium installati senza licenza, che non possono essere aggiornati.

Se un cliente non vuole pagare la licenza, la nostra posizione è chiara: rimuoviamo il plugin. Non possiamo difendere un sito che ospita codice non aggiornabile da remoto.

3. Password forti e univoche, ovunque

Password riutilizzate sono il vettore più banale e più sottovalutato. Vale per:

• utenti admin WordPress
• accesso FTP/SSH/hosting
• database
• API e integrazioni esterne

Non importa quanto sia "complessa" una password se è la stessa che il cliente ha usato su un forum compromesso anni fa. Usiamo password manager (Bitwarden, 1Password) e generatori automatici: 24 caratteri random, mai a memoria.

4. Autenticazione a due fattori per tutti gli admin

2FA è il singolo intervento con miglior rapporto sforzo/risultato. Una volta attivato, le campagne di brute force su wp-login.php diventano sostanzialmente innocue.

Plugin consigliati: WP 2FA, Two Factor (di Plugin Vendor), oppure soluzioni più strutturate via WP-CLI. Non basta installarlo: va imposto a tutti gli admin con ruolo Administrator e Editor, e va testata la procedura di recupero.

5. Limitare i tentativi di login

Anche con 2FA, conviene rallentare gli script automatici. Plugin come Limit Login Attempts Reloaded (versione recente, mantenuta) o impostazioni a livello server (fail2ban su wp-login.php) bloccano IP che falliscono troppi tentativi.

Una buona configurazione di base: 5 tentativi, lockout 30 minuti, blacklist progressiva su recidivi.

6. Disabilitare XML-RPC se non serve

xmlrpc.php è una superficie di attacco storica ed è raramente necessaria nei siti moderni. Lo serve principalmente Jetpack e qualche app mobile. Se non lo usi, disabilitalo a livello server:

<Files "xmlrpc.php">
  Require all denied
</Files>

Se lo usi solo da Jetpack, restringilo agli IP del servizio.

7. Disabilitare l'editor file da Bacheca

WordPress permette di modificare file di tema e plugin direttamente da pannello. È una funzione utile per sviluppatori, ma una volta in produzione diventa solo un'arma in mano a chi prende il controllo dell'admin. Va disabilitata sempre:

define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);

DISALLOW_FILE_MODS impedisce anche installazione e aggiornamento di plugin/temi da pannello: utile su siti dove gli aggiornamenti vengono gestiti con processo controllato.

8. File permission corretti

WordPress richiede permessi che spesso vengono lasciati troppo larghi durante installazione, migrazione o intervento d'emergenza. La baseline che applichiamo:

• file: 644
• cartelle: 755
• wp-config.php: 600 (o 640 se l'utente Apache è nello stesso gruppo)
• .htaccess: 644

Mai 777, mai chown ricorsivi a nobody:nobody "perchè così funziona".

9. Ruotare i SALT in wp-config.php

Le chiavi SALT/SECRET in wp-config.php invalidano i cookie esistenti quando vengono cambiate. È un'operazione da fare:

• alla prima messa in produzione
• dopo ogni sospetto di compromissione
• almeno una volta all'anno per i siti più sensibili

Le si genera con un click da https://api.wordpress.org/secret-key/1.1/salt/. Cambia tutto in blocco, non una alla volta.

10. Headers di sicurezza HTTP

A livello server o via plugin (preferiamo a livello server), almeno questi:

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

Una Content Security Policy stretta è ottima ma richiede tuning per non rompere widget legittimi: la valutiamo caso per caso.

11. Backup verificati e separati

Avere un backup non significa nulla se non lo hai mai testato. Un backup non testato è una scommessa, non una protezione. Quello che facciamo:

• backup giornalieri offsite (non sullo stesso hosting del sito)
• retention almeno 14 giorni
• test mensile di ripristino su staging
• documentazione della procedura: chiunque del team deve poter ripristinare

Backup sul medesimo hosting del sito vengono cifrati o cancellati insieme al sito quando l'hosting viene preso. Devono stare altrove.

12. Monitoraggio file e log di accesso

Il monitoraggio non previene gli attacchi, ma li rende visibili presto. Cose utili:

• alert su modifiche file inattese (WP-CLI checksum, AIDE, Tripwire)
• alert su login admin riusciti da IP nuovi
• alert su uptime e DNS
• review periodica dei log Apache/Nginx

In manutenzione continuativa lo facciamo tramite controllo settimanale automatico, con escalation umana solo sulle anomalie.

Quello che NON è in questa lista, e perché

Sono volutamente fuori dal "core" dell'hardening:

• Cambiare il prefisso di tabella wp_: poco utile contro attaccanti reali, complica le migrazioni.
• Nascondere la versione di WordPress: security through obscurity, non sposta il rischio.
• Cambiare URL di login: rallenta i bot stupidi ma non quelli mirati. Va valutato caso per caso.
• Plugin "all-in-one security" con 200 funzioni: spesso fanno danni, conflitti, e mascherano i problemi reali sotto strati di toggle. Preferiamo plugin specifici e ben mantenuti.

Hardening è un processo, non un evento

Una configurazione di hardening fatta oggi non protegge per sempre. Plugin nuovi, dipendenze aggiornate, configurazioni cambiate: ogni mese qualcosa si sposta. Per questo l'hardening reale convive con la manutenzione continuativa.

Se ti serve una verifica di hardening sul tuo sito, scrivici via chat. Bob, il nostro assistente, ti aiuta a capire da dove partire.