La sicurezza WordPress non è un singolo plugin. È una somma di scelte: componenti aggiornati, credenziali robuste, permessi corretti, backup verificati e monitoraggio. Un sito può essere vulnerabile anche con il core aggiornato se il resto della superficie d'attacco è trascurato.
Per uno sviluppatore, l'obiettivo non è rendere il sito "invulnerabile". L'obiettivo realistico è ridurre il rischio, rendere gli attacchi comuni meno efficaci e garantire un ripristino rapido quando qualcosa va storto.
Aggiornamento luglio 2026
Nel 2026 la priorità non è solo "aggiornare WordPress". La superficie reale è composta da plugin, temi, credenziali, hosting, pipeline di deploy, backup e integrazioni esterne. WordPress 7.0 introduce connessioni standardizzate e strumenti AI opzionali: utili, ma da trattare come nuove integrazioni con permessi, log, provider e policy dati da verificare.
La best practice aggiornata è separare manutenzione ordinaria e hardening. La manutenzione applica update rapidi e controllati; l'hardening riduce privilegi, accessi e scrittura. Usa 2FA, password manager, ruoli minimi, DISALLOW_FILE_EDIT, backup off-site testati e WAF configurato. Per i plugin, controlla frequenza di aggiornamento, changelog, compatibilità PHP e reputazione del maintainer prima di installare.
Nei siti business conviene bloccare l'installazione libera di plugin in produzione: le modifiche passano da staging, review e rollback.
Superficie d'attacco più comune
Nella pratica, i problemi arrivano spesso da:
- plugin non aggiornati o abbandonati;
- temi premium pieni di dipendenze vecchie;
- credenziali riutilizzate;
- accesso admin senza 2FA;
- hosting non isolato;
- backup mai testati;
- permessi file troppo permissivi.
Il primo hardening è togliere ciò che non serve. Ogni plugin installato è codice in più da aggiornare, controllare e proteggere.
Hardening minimo
Le misure di base sono semplici, ma vanno applicate con disciplina. Anche l'automazione con WP-CLI aiuta, se rende backup e update ripetibili invece che manuali.
Attiva la 2FA per tutti gli account amministrativi. Limita i tentativi di login. Usa password manager e ruoli corretti: non tutti devono essere amministratori.
Se XML-RPC non serve, disabilitalo o filtralo. Molti siti non usano più client esterni o pingback, quindi lasciarlo aperto aumenta il rumore senza beneficio reale.
Nascondere /wp-admin non è una strategia di sicurezza sufficiente. Può ridurre bot automatici, ma non sostituisce autenticazione forte, aggiornamenti e controlli lato server.
File system e permessi
Il file wp-config.php deve essere protetto. Le chiavi salts devono essere robuste e, in caso di compromissione, ruotate. I permessi non devono permettere scrittura indiscriminata.
Indicazioni generali:
- file a
644; - directory a
755; - niente editor file dal pannello admin;
- scrittura limitata alle directory che ne hanno bisogno;
- separazione tra ambienti e utenti server.
In wp-config.php conviene disabilitare l'editor interno:
define('DISALLOW_FILE_EDIT', true);Se un attaccante ottiene accesso admin, non deve poter modificare direttamente plugin e temi dal backend.
Database
Cambiare il prefisso tabelle non basta, ma può aiutare in installazioni nuove. Più importante è usare un utente database con privilegi coerenti: WordPress non dovrebbe connettersi con un utente più potente del necessario.
Evita di lasciare dump SQL in directory pubbliche. Dopo una migrazione, rimuovi archivi, backup temporanei e file .sql. Molte compromissioni partono da file dimenticati.
WAF e monitoring
Cloudflare, Sucuri, Wordfence e strumenti simili possono aiutare, ma vanno configurati. Un WAF riduce traffico malevolo, bot e tentativi automatici. Non corregge un plugin vulnerabile né sostituisce gli aggiornamenti.
Il monitoring deve includere:
- uptime;
- error log;
- modifiche ai file;
- login sospetti;
- scansione malware;
- scadenza certificati;
- stato backup.
Backup 3-2-1 e ripristino
Un backup non testato è una speranza, non una strategia. La regola 3-2-1 resta valida: tre copie, due supporti diversi, una copia fuori dall'ambiente principale.
Per WordPress bisogna salvare database e media. Il codice dovrebbe stare in Git quando possibile. Va provato anche un restore completo in staging: solo così si scoprono backup corrotti, path sbagliati o plugin mancanti.
Checklist finale
- Core, plugin e temi aggiornati.
- Plugin inutili rimossi.
- 2FA attiva sugli admin.
- XML-RPC disabilitato se non serve.
DISALLOW_FILE_EDITattivo.- Permessi file controllati.
- WAF configurato.
- Backup automatici e restore testato.
- Accessi e log monitorati.
Conclusione
L'hardening WordPress funziona quando diventa routine. Non serve una configurazione spettacolare: serve una base coerente, documentata e verificabile. Meno componenti, più controllo e backup testati sono ancora le scelte più efficaci, soprattutto in un progetto di sviluppo WordPress mantenibile.