La sicurezza di un sito WordPress non è un interruttore che si accende installando un plugin: è un processo continuo, fatto di aggiornamenti regolari, accessi ben gestiti, backup affidabili e scelte consapevoli. Il plugin è solo un tassello.
Quando si parla di sicurezza in WordPress, la prima reazione è quasi sempre la stessa: «quale plugin devo installare?». È una domanda comprensibile, ma rivela un equivoco di fondo. Un plugin di sicurezza può aiutare, però non rende un sito «sicuro» una volta per tutte. La sicurezza non è uno stato che si raggiunge, ma un’abitudine che si mantiene nel tempo.
In questo articolo vediamo perché la sicurezza è prima di tutto un processo, e quali pratiche concrete possono adottare le persone che usano WordPress ogni giorno: dalle utenti e dagli utenti che pubblicano contenuti, fino a chi sviluppa temi e plugin.
Perché un plugin di sicurezza non basta
Un plugin di sicurezza fa cose utili: aggiunge un firewall applicativo, limita i tentativi di login, esegue scansioni alla ricerca di file sospetti. Ma agisce su una parte sola del problema, e soprattutto non sostituisce le abitudini di chi gestisce il sito.
La maggior parte delle violazioni non avviene perché manca un plugin, bensì perché qualcosa nel processo è stato trascurato: un aggiornamento rimandato per mesi, una password riutilizzata, un account con permessi troppo ampi, un backup che nessuno aveva mai provato a ripristinare. Nessun plugin può proteggere da un’installazione lasciata indietro di tre versioni o da una password come admin123.
Pensare alla sicurezza come a un processo significa spostare l’attenzione dallo strumento alle abitudini. Lo strumento aiuta, ma è la costanza a fare la differenza.
Aggiornamenti: la difesa più sottovalutata
Tenere aggiornati il core di WordPress, i temi e i plugin è probabilmente la singola pratica più efficace e, allo stesso tempo, la più trascurata. Le vulnerabilità note vengono corrette con gli aggiornamenti: un sito non aggiornato resta esposto a problemi per cui esiste già una soluzione pubblica, e quindi facilmente sfruttabile.
Lo stesso vale per la versione di PHP su cui gira il sito. Le versioni vecchie non ricevono più correzioni di sicurezza, come abbiamo visto parlando dell’interruzione del supporto per PHP 7.2 e 7.3. Restare su una versione obsoleta significa accumulare rischi che nessun plugin di sicurezza può compensare.
Il processo, qui, è semplice da descrivere e va reso un’abitudine: aggiornare con regolarità, controllare la compatibilità prima dei salti di versione importanti, e fare sempre un backup prima di un aggiornamento rilevante. Prima di passare a una nuova versione di WordPress vale la pena dare un’occhiata alle indicazioni del Team Hosting, come quelle sulla compatibilità con i server in WordPress 6.9.
Accessi e ruoli: il principio del privilegio minimo
Ogni account è una possibile porta d’ingresso. Più account amministratori esistono, più ampia è la superficie d’attacco. Il principio del privilegio minimo dice una cosa semplice: ogni persona dovrebbe avere solo i permessi che le servono davvero, niente di più.
WordPress mette a disposizione un sistema di ruoli pensato esattamente per questo. Una persona che si occupa solo di scrivere articoli non ha bisogno del ruolo di amministratore: il ruolo di autore o editore è più che sufficiente. Assegnare i ruoli con criterio riduce i danni possibili se un account viene compromesso. Abbiamo approfondito questo tema nell’articolo sui ruoli utente: cosa sono e come sfruttarli al meglio.
Anche qui si tratta di processo, non di un singolo intervento: rivedere periodicamente chi ha accesso, rimuovere gli account che non servono più, e non lasciare attivo l’utente admin predefinito sono abitudini che vanno mantenute nel tempo.
Password, autenticazione e sessioni
Le password deboli o riutilizzate restano una delle cause più comuni di accesso non autorizzato. La buona pratica è nota ma vale la pena ripeterla: password lunghe e uniche per ogni servizio, gestite con un password manager, e l’autenticazione a due fattori (2FA) attiva almeno per gli account con permessi elevati.
L’autenticazione a due fattori è particolarmente importante perché aggiunge una barriera che la sola password non può superare: anche se una credenziale viene rubata, l’accesso resta bloccato senza il secondo fattore. È una di quelle misure che, da sole, alzano sensibilmente il livello di protezione.
A questo si aggiunge l’attenzione alla pagina di login, spesso il primo bersaglio dei tentativi automatici. Limitare i tentativi di accesso falliti e disconnettere le sessioni inattive sono accorgimenti utili, e sono proprio le funzioni che molti plugin di sicurezza offrono. Restano però un complemento alle buone abitudini, non un loro sostituto.
Backup: il piano B che salva il progetto
Nessuna misura di sicurezza è infallibile. Per questo il backup non è un dettaglio, ma la rete di protezione che permette di rimettere in piedi un sito dopo un problema, che sia un attacco, un aggiornamento andato male o un errore umano.
Un backup è davvero utile solo se rispetta tre condizioni: è regolare, è conservato in un luogo separato dal sito (non solo sullo stesso server) e, soprattutto, è stato verificato almeno una volta provando un ripristino. Un backup mai testato è una speranza, non una garanzia.
Anche il backup, come tutto il resto, è un processo: va automatizzato, controllato periodicamente e adattato alla frequenza con cui il sito cambia. Un blog aggiornato ogni giorno ha bisogno di una cadenza diversa rispetto a un sito vetrina che cambia poche volte all’anno.
Hosting e configurazione: la base su cui poggia tutto
La sicurezza comincia da dove il sito è ospitato. Un buon hosting fornisce aggiornamenti del server, isolamento tra i siti, certificati SSL e spesso backup automatici. La scelta tra hosting condiviso, VPS e server dedicato incide direttamente sul grado di controllo e di isolamento, come abbiamo spiegato nell’articolo sulle differenze tra hosting condiviso, VPS e dedicato.
Sul fronte della configurazione, alcune buone pratiche fanno parte del processo di base: servire l’intero sito in HTTPS con un certificato valido, usare connessioni sicure per il trasferimento dei file evitando l’FTP in chiaro, e mantenere ordinati i permessi dei file. Anche un file apparentemente innocuo come robots.txt rientra in una gestione consapevole di ciò che il sito espone all’esterno.
Sicurezza lato sviluppo: il processo nel codice
Per chi sviluppa temi e plugin, la sicurezza si gioca soprattutto nel codice, e qui l’idea di «processo» diventa ancora più concreta. La maggior parte delle vulnerabilità nasce da pochi errori ricorrenti: dati in ingresso non validati, output non correttamente filtrato (escaping), query al database costruite senza preparazione. La regola di base è sempre la stessa: non fidarsi mai dei dati che arrivano dall’esterno.
Il modo più affidabile per gestire questi rischi non è il controllo manuale a fine progetto, ma un processo automatizzato che li intercetti prima che arrivino in produzione. Gli strumenti che abbiamo già visto nella serie compongono esattamente questa rete di sicurezza:
- I Coding Standards con PHPCS e WPCS segnalano automaticamente pattern pericolosi, come output non filtrati o funzioni sconsigliate.
- L’analisi statica con PHPStan individua errori di tipo e flussi sospetti prima ancora di eseguire il codice.
- I test automatizzati con PHPUnit verificano che il comportamento atteso resti tale anche dopo le modifiche, evitando regressioni che potrebbero reintrodurre vulnerabilità.
- Le GitHub Actions eseguono tutti questi controlli a ogni modifica, in modo che nessuno se ne dimentichi.
In altre parole, la sicurezza del codice non è un’ispezione finale ma una pipeline: ogni modifica passa attraverso gli stessi controlli, automaticamente. È il principio «processo, non solo plugin» applicato allo sviluppo.
Cosa fa (e cosa non fa) un plugin di sicurezza
Chiarito tutto questo, un plugin di sicurezza ha comunque il suo posto. Può centralizzare funzioni utili (firewall, limitazione dei login, scansioni, notifiche) e semplificare la vita soprattutto a chi non ha competenze tecniche avanzate. Usarlo è una buona idea.
Quello che un plugin non può fare è sostituire le abitudini: non aggiornerà al posto nostro un sito abbandonato, non sceglierà password migliori, non rivedrà i ruoli degli utenti, non garantirà che esista un backup funzionante. Il plugin è uno strumento dentro il processo, non il processo stesso.
La sintesi è questa: installare un plugin di sicurezza e considerare il lavoro concluso è il vero rischio. Inserirlo in un insieme di pratiche regolari è ciò che lo rende davvero utile.
Una checklist di sicurezza come routine
Per trasformare questi principi in qualcosa di concreto e ripetibile, aiuta avere una checklist da rivedere periodicamente:
- Core di WordPress, temi e plugin aggiornati, e versione di PHP ancora supportata.
- Solo gli account necessari, ciascuno con il ruolo minimo indispensabile.
- Password forti e uniche, con autenticazione a due fattori sugli account sensibili.
- Backup automatici, conservati altrove e verificati con un ripristino di prova.
- Sito interamente in HTTPS e trasferimenti file su connessioni sicure.
- Per chi sviluppa: controlli automatici (standard, analisi statica, test) attivi a ogni modifica.
Una checklist simile si integra naturalmente con quella più generale che abbiamo proposto nell’articolo sulla checklist di controllo per il primo sito WordPress: la sicurezza non è una sezione a parte, ma parte integrante della cura ordinaria di un sito.
Prossimi passi
La sicurezza di WordPress non si compra con un plugin: si costruisce con la costanza. Aggiornare, gestire gli accessi con criterio, proteggere i login, mantenere backup affidabili e, per chi sviluppa, automatizzare i controlli sul codice sono le abitudini che, messe insieme, fanno la vera differenza.
Il consiglio pratico è partire da un punto solo: scegliere una delle pratiche descritte qui, trasformarla in una routine, e poi aggiungerne un’altra. Un processo di sicurezza solido non nasce tutto in una volta, ma un’abitudine alla volta.
