Un sito WordPress è robusto quanto il suo plugin, account o backup più debole. Il core di WordPress riceve regolarmente aggiornamenti di sicurezza; ciò che vi si aggiunge e il modo in cui lo si gestisce dipendono da lei. Questa checklist copre i controlli più importanti, più o meno nell’ordine in cui li applicheremmo noi.
1. Mantenere aggiornati core, plugin e temi
Gli aggiornamenti automatici in background del core esistono da WordPress 3.7 e per impostazione predefinita riguardano le release minori. Da WordPress 5.5 è possibile attivare gli aggiornamenti automatici anche per ogni singolo plugin e tema dalle schermate di amministrazione.
- Attivi gli aggiornamenti automatici per i plugin di sviluppatori affidabili e controlli gli altri ogni settimana.
- Gli aggiornamenti automatici si basano su WP-Cron. Controlli eventuali errori in Strumenti > Salute del sito, perché se il cron non funziona gli aggiornamenti si interrompono senza alcun avviso.
- Si assicuri di poter tornare alla versione precedente prima di affidarsi agli aggiornamenti automatici. Lo raccomanda anche la documentazione di WordPress.
2. Rimuovere i plugin abbandonati e inutilizzati
La guida all’hardening di WordPress è chiara: mantenga aggiornati i plugin ed elimini quelli che non usa. Disattivarli non basta, perché il codice resta sul server.
La directory dei plugin di WordPress.org offre due segnali d’allarme:
- Un avviso giallo che indica che un plugin “non è stato testato con le ultime 3 versioni principali di WordPress”.
- Un avviso rosso che indica che un plugin è stato chiuso e non è più disponibile per il download. Dopo 60 giorni viene mostrato il motivo, e “problema di sicurezza” è uno dei motivi previsti.
Un plugin chiuso non riceverà aggiornamenti tramite WordPress.org. Lo sostituisca. Non installi mai copie “nulled” di plugin premium e installi solo da WordPress.org o da fornitori di cui si fida.
3. Verificare gli account amministratore
Elenchi tutti gli account con il ruolo Amministratore e rimuova quelli di cui nessuno sa spiegare l’esistenza. Con WP-CLI:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredDia a ogni persona un proprio account nominativo, mai un login admin condiviso. Usi il ruolo più basso sufficiente per il lavoro: la maggior parte dei redattori non ha bisogno del ruolo Amministratore. Richieda password robuste e uniche, idealmente conservate in un password manager.
4. Attivare l’autenticazione a due fattori
Attivi la 2FA per ogni amministratore. Il core di WordPress non include la 2FA, quindi serve un plugin o un provider di single sign-on che la imponga. Preferisca metodi come chiavi di sicurezza o passkey, se il plugin li supporta, e conservi i codici di recupero in un luogo sicuro.
5. Limitare i tentativi di login e decidere su XML-RPC
La documentazione di WordPress descrive wp-login.php e xmlrpc.php come bersagli comuni degli attacchi brute force. Raccomanda di limitare i tentativi di login a livello di edge (un WAF o una CDN) o di web server. Anche un plugin di sicurezza può rallentare i login, ma viene eseguito in PHP, quindi l’opzione a livello di server regge meglio sotto traffico intenso.
Se non usa XML-RPC, lo disattivi. Alcune app mobile e servizi come Jetpack ne hanno bisogno, quindi verifichi prima. Tenga presente che il filtro xmlrpc_enabled disattiva solo i metodi che richiedono autenticazione. I pingback e gli altri metodi non autenticati continuano a funzionare. Per disattivarlo del tutto, blocchi il file a livello di web server. Per nginx:
location = /xmlrpc.php {
deny all;
}6. Disattivare l’editor di file integrato
L’editor di temi e plugin della bacheca permette a chiunque abbia una sessione da amministratore di modificare codice PHP. Lo disattivi in wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );Secondo la documentazione di wp-config.php, DISALLOW_FILE_MODS va oltre e blocca anche l’installazione e l’aggiornamento di plugin e temi dalla bacheca. Lo usi solo se distribuisce le modifiche in un altro modo, ad esempio tramite Git o WP-CLI.
7. Tenere i backup fuori dal server e fuori dalla web root
La guida all’hardening raccomanda backup regolari sia dei file sia del database, più snapshot e una posizione di archiviazione affidabile. Ne protegga l’integrità con la cifratura, con hash registrati o con supporti di sola lettura.
Ne derivano due regole pratiche. Un backup all’interno della web root, come un file zip in wp-content, può essere scaricato da chiunque ne indovini il nome. Un backup sullo stesso server può essere cancellato dallo stesso attaccante. Conservi almeno una copia in un luogo che le credenziali del sito non possono raggiungere, e verifichi un ripristino completo.
8. Verificare l’integrità dei file
WP-CLI può confrontare i file con i checksum ufficiali di WordPress.org senza caricare WordPress:
wp core verify-checksums --include-root
wp plugin verify-checksums --allIl primo comando segnala i file del core modificati, e --include-root avvisa della presenza di file inattesi nella directory principale. Il secondo confronta i plugin con i checksum di WordPress.org, quindi è utile solo per i plugin ospitati lì. Cerchi anche file PHP in wp-content/uploads, che normalmente dovrebbe contenere solo file multimediali.
9. Usare un utente del database con privilegi minimi
Assegni a ogni sito un proprio database e un proprio utente del database, con diritti solo su quel database. Non si connetta mai come utente root del database.
La guida all’hardening osserva che il funzionamento quotidiano richiede solo SELECT, INSERT, UPDATE e DELETE. Non raccomanda di revocare DROP, ALTER e GRANT, perché i plugin e gli aggiornamenti principali potrebbero dover modificare lo schema. Se li rimuove comunque, mantenga backup collaudati.
10. Impostare i permessi dei file
Il punto di partenza della guida è 755 per le directory e 644 per i file. I file del core, wp-admin e wp-includes dovrebbero essere scrivibili solo dal suo account utente, non dal web server. wp-content è l’eccezione: il web server deve poterci scrivere per i caricamenti. Per wp-config.php la guida suggerisce 400 o 440.
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;
chmod 440 /var/www/example/wp-config.phpAdatti percorsi e proprietari alla sua configurazione di hosting prima di eseguire questi comandi.
11. Inviare header di sicurezza
Header come Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options e Referrer-Policy aggiungono protezione lato browser. Se possibile, li imposti a livello di web server o di CDN anziché tramite un plugin. Inizi con una Content Security Policy in modalità report-only, perché temi e page builder potrebbero basarsi su script inline.
12. Mettere un WAF davanti al sito
La documentazione di WordPress descrive tre livelli: plugin di sicurezza che filtrano le richieste all’interno di WordPress, un firewall a livello di server come ModSecurity e servizi di reverse proxy che filtrano il traffico prima che raggiunga il server. Più il filtraggio avviene all’esterno, minore è il carico che arriva a PHP. Un WAF non sostituisce gli aggiornamenti. Fa guadagnare tempo tra la divulgazione di una vulnerabilità e l’applicazione della patch.
In breve
| Area | Minimo |
|---|---|
| Aggiornamenti | Aggiornamenti automatici minori del core attivi, plugin controllati ogni settimana |
| Plugin | Nessun plugin chiuso, abbandonato o inutilizzato installato |
| Account | Account nominativi, pochi amministratori, 2FA per tutti |
| Login | Limitazione dei tentativi a livello di server o di edge, XML-RPC bloccato se non usato |
| Modifiche al codice | DISALLOW_FILE_EDIT impostato |
| Backup | Fuori dal server, fuori dalla web root, ripristino verificato |
| Integrità | Checksum verificati, nessun file PHP negli upload |
| Database | Un utente per sito, con diritti solo sul proprio database |
| Browser | HSTS e una CSP collaudata |
| Perimetro | WAF o reverse proxy davanti al sito |
Da dove iniziare
Inizi dai primi quattro punti. Richiedono poco tempo e nessuna modifica all’hosting. Poi verifichi gli header attuali con il nostro scanner degli header di sicurezza.
Se desidera che questa verifica venga fatta per lei, SecAudit analizza WordPress alla ricerca di malware e web shell, verifica l’integrità dei file rispetto ai checksum ufficiali e associa i plugin installati alle vulnerabilità note.
