Sicurezza WordPress: Gli Errori Commessi Più Spesso

18 Luglio 2026 Ottimizzazione by e.reali

Gli errori di sicurezza WordPress più frequenti non dipendono necessariamente da attacchi particolarmente complessi. Spesso nascono da plugin abbandonati, account amministrativi condivisi, password deboli, backup mai verificati e configurazioni lasciate senza manutenzione.

Un sito può continuare a funzionare apparentemente bene anche quando presenta problemi importanti. Un accesso non autorizzato può essere utilizzato per creare utenti nascosti, inserire collegamenti, inviare messaggi indesiderati, modificare file o reindirizzare soltanto una parte delle visite.

La sicurezza non coincide quindi con l’assenza di errori visibili. Deve essere valutata controllando il sito, il server, gli utenti, i componenti installati e le procedure utilizzate per amministrarlo.

Non esiste una configurazione capace di rendere WordPress sicuro una volta per tutte. La protezione deriva da più livelli che devono essere mantenuti e aggiornati nel tempo.

Sicurezza WordPress: Gli Errori Commessi Più Spesso

Gli errori possono riguardare aree molto differenti:

WordPress non aggiornato;
plugin e temi vulnerabili;
account amministrativi non necessari;
password riutilizzate;
assenza di autenticazione a due fattori;
backup incompleti;
hosting non adeguato;
permessi dei file errati;
moduli e caricamenti non protetti;
strumenti di sicurezza configurati male;
ambienti di test lasciati pubblici;
assenza di controlli dopo gli aggiornamenti.

La presenza di un plugin di sicurezza non elimina automaticamente questi problemi. Un componente può aiutare a limitare gli accessi, registrare attività o rilevare modifiche, ma non può sostituire una gestione corretta del sito.

Aggiornare WordPress Troppo Tardi

Uno degli errori più comuni consiste nel rimandare gli aggiornamenti per lunghi periodi.

Gli aggiornamenti possono includere:

correzioni di sicurezza;
risoluzione di errori;
compatibilità con PHP;
miglioramenti delle funzioni;
modifiche alle API;
correzioni relative all’editor e all’amministrazione.

Rinviare ogni aggiornamento per timore di creare problemi non rappresenta una strategia sicura. Allo stesso tempo, aggiornare componenti importanti senza alcun controllo può interrompere funzioni essenziali.

La procedura corretta consiste nel valutare il tipo di aggiornamento, verificare la compatibilità e controllare il sito dopo l’installazione.

Per progetti complessi è preferibile effettuare prima la prova in un ambiente separato, soprattutto quando l’aggiornamento riguarda e-commerce, prenotazioni, aree riservate o plugin personalizzati.

Lasciare Plugin e Temi Abbandonati

Un plugin può continuare a funzionare per anni anche senza ricevere aggiornamenti. Questo non significa che continui a essere sicuro o compatibile.

Un componente abbandonato può utilizzare:

funzioni obsolete;
librerie non aggiornate;
metodi di validazione insufficienti;
API non più supportate;
codice incompatibile con versioni recenti di PHP;
procedure di autenticazione superate.

Quando controllo i componenti installati, non considero soltanto la data dell’ultimo aggiornamento. Valuto anche la complessità del plugin, le funzioni che gestisce e il livello di accesso ai dati.

Un piccolo componente amministrativo non presenta necessariamente gli stessi rischi di un plugin che gestisce caricamenti, registrazioni, pagamenti o richieste provenienti dall’esterno.

Mantenere Plugin Inutilizzati

Un plugin disattivato non viene normalmente eseguito come un componente attivo, ma i suoi file restano comunque presenti sul server.

Conservare numerosi plugin inutilizzati rende più difficile:

capire quali componenti servano davvero;
controllare gli aggiornamenti;
individuare file sospetti;
gestire correttamente le licenze;
ridurre la superficie del progetto;
mantenere ordinato l’ambiente.

Quando un componente non è più necessario, valuto prima quali dati abbia salvato e poi procedo alla sua rimozione.

La disinstallazione deve essere gestita con attenzione, perché alcuni plugin eliminano le proprie tabelle mentre altri lasciano impostazioni, metadati e attività programmate.

Utilizzare Plugin o Temi Provenienti da Fonti Non Verificate

Installare versioni modificate di plugin commerciali è uno degli errori più rischiosi.

Un archivio scaricato da una fonte non ufficiale può contenere:

codice aggiuntivo;
accessi nascosti;
script esterni;
collegamenti inseriti automaticamente;
sistemi di raccolta dei dati;
file mascherati;
modifiche che impediscono gli aggiornamenti.

Il fatto che il plugin si attivi e svolga la propria funzione non dimostra che il codice sia identico alla versione originale.

Quando il sito gestisce dati aziendali, richieste di contatto, utenti o pagamenti, l’origine dei componenti deve essere sempre verificabile.

Condividere lo Stesso Account Amministratore

Utilizzare un solo account amministrativo per più persone rende difficile capire chi abbia eseguito una determinata operazione.

Inoltre, quando un collaboratore termina il proprio incarico, diventa necessario cambiare la password per tutti.

Ogni persona dovrebbe avere un account individuale con:

nome riconoscibile;
email personale o aziendale;
password separata;
ruolo proporzionato alle attività;
accesso rimosso quando non più necessario.

Gli account individuali migliorano la tracciabilità e permettono di revocare un solo accesso senza modificare le credenziali degli altri utenti.

Assegnare il Ruolo di Amministratore a Tutti

Il ruolo di amministratore consente di modificare impostazioni, installare componenti, creare utenti e intervenire sulle parti principali del sito.

Non dovrebbe essere assegnato automaticamente a chi deve soltanto:

pubblicare articoli;
modificare testi;
gestire prodotti;
consultare richieste;
aggiornare immagini;
rispondere a ordini;
lavorare su una singola sezione.

La regola da applicare è concedere a ogni utente soltanto i permessi necessari per svolgere il proprio lavoro.

Limitare i privilegi riduce sia il rischio di errori involontari sia le conseguenze di un account compromesso.

Non Rimuovere gli Account Non Più Utilizzati

Collaboratori, agenzie, sviluppatori e dipendenti possono avere bisogno di accedere al sito per un periodo limitato.

Quando il rapporto termina, l’account viene spesso dimenticato.

Durante un controllo verifico:

data dell’ultimo accesso;
ruolo assegnato;
email collegata;
identità del proprietario;
necessità effettiva dell’account;
eventuali chiavi applicative;
accessi collegati a servizi esterni.

Gli account non identificabili o non più necessari devono essere rimossi o disabilitati dopo aver gestito correttamente i contenuti associati.

Utilizzare Password Deboli o Riutilizzate

Una password può essere complessa e continuare a essere rischiosa se viene utilizzata su più servizi.

Quando una credenziale viene esposta altrove, può essere provata automaticamente anche su WordPress, hosting, email e altri pannelli.

Le password dovrebbero essere:

lunghe;
uniche;
generate casualmente;
conservate in un gestore dedicato;
differenti per ogni servizio;
modificate quando esiste un sospetto concreto di compromissione.

Evitare password brevi o prevedibili è importante, ma lo è ancora di più non riutilizzare la stessa credenziale per più account.

Non Attivare l’Autenticazione a Due Fattori

L’autenticazione a due fattori aggiunge un controllo ulteriore oltre alla password.

È particolarmente utile per:

amministratori;
sviluppatori;
gestori del negozio;
utenti con accesso ai dati personali;
account dell’hosting;
servizi di registrazione del dominio;
caselle email utilizzate per recuperare le credenziali.

Proteggere soltanto WordPress non è sufficiente se l’email collegata all’amministratore può essere utilizzata per reimpostare la password.

La protezione deve comprendere tutti i servizi capaci di concedere o recuperare l’accesso al sito.

Proteggere WordPress ma Dimenticare l’Hosting

Il sito dipende dall’ambiente nel quale viene eseguito.

Un accesso al pannello di hosting può permettere di:

modificare i file;
scaricare il database;
creare account FTP;
gestire domini e sottodomini;
modificare PHP;
leggere configurazioni;
creare backup;
interrompere il sito.

Le credenziali dell’hosting devono quindi essere protette con la stessa attenzione riservata agli account amministrativi di WordPress.

Quando disponibile, attivo l’autenticazione a due fattori e rimuovo gli account FTP o SFTP non più utilizzati.

Utilizzare una Versione Obsoleta di PHP

WordPress viene eseguito attraverso PHP. Una versione non più supportata può non ricevere correzioni di sicurezza e può creare incompatibilità con componenti recenti.

L’aggiornamento deve però essere preparato verificando:

tema attivo;
plugin principali;
plugin personalizzati;
funzioni del tema child;
integrazioni esterne;
log degli errori;
attività programmate;
versione minima richiesta dai componenti.

Passare direttamente a una nuova versione senza controlli può provocare errori. Mantenere per anni una versione obsoleta è però un rischio maggiore.

Credere che Cambiare il Prefisso del Database Risolva la Sicurezza

Modificare il prefisso standard delle tabelle può ridurre l’efficacia di alcuni tentativi molto semplici, ma non rappresenta una protezione completa.

Non impedisce problemi legati a:

plugin vulnerabili;
password compromesse;
query non preparate;
account amministrativi esposti;
file modificati;
hosting compromesso;
permessi errati;
servizi esterni vulnerabili.

Concentrarsi su una modifica cosmetica e trascurare aggiornamenti, accessi e componenti produce una falsa sensazione di sicurezza.

Installare un Plugin di Sicurezza e Considerare il Lavoro Concluso

Un plugin di sicurezza può offrire strumenti utili:

limitazione dei tentativi di accesso;
autenticazione a due fattori;
registrazione delle attività;
controllo dell’integrità dei file;
blocco di richieste sospette;
notifiche;
scansione dei componenti;
regole di protezione.

Questi strumenti devono però essere configurati e controllati.

Un plugin lasciato con impostazioni casuali può produrre numerose notifiche inutili, bloccare utenti legittimi oppure non proteggere le aree realmente importanti.

La sicurezza non migliora semplicemente aumentando il numero di funzioni attive.

Configurare Regole Troppo Aggressive

Bloccare qualsiasi richiesta insolita può sembrare una buona strategia, ma può interrompere:

moduli;
pagamenti;
API;
integrazioni;
webhook;
attività programmate;
strumenti di monitoraggio;
accessi legittimi da reti differenti.

Ogni regola deve essere proporzionata al sito e testata sulle funzioni reali.

Un negozio, un sito editoriale e un portale con area riservata non possono essere protetti attraverso la stessa configurazione applicata senza adattamenti.

Non Limitare i Tentativi di Accesso

La schermata di accesso può ricevere tentativi automatici basati su elenchi di nomi utente e password.

Tra le misure utili considero:

limitazione dei tentativi;
autenticazione a due fattori;
password uniche;
protezione degli account amministrativi;
registrazione degli accessi falliti;
eventuale protezione aggiuntiva delle aree riservate.

Nascondere l’indirizzo di accesso può ridurre una parte del traffico automatico, ma non deve essere considerato il principale sistema di protezione.

Mostrare Informazioni Tecniche negli Errori

Messaggi di errore dettagliati possono rivelare:

percorsi dei file;
nomi delle directory;
plugin installati;
query;
struttura del codice;
nomi di funzioni;
informazioni sull’ambiente.

Durante lo sviluppo i log tecnici sono indispensabili. Nel sito pubblico non dovrebbero essere mostrati direttamente agli utenti.

Gli errori devono essere registrati in modo controllato e consultabili soltanto da chi gestisce il progetto.

Lasciare la Modalità Debug Attiva sul Sito Pubblico

La modalità debug aiuta a individuare errori, avvisi e comportamenti anomali.

Se viene configurata per mostrare direttamente le informazioni nella pagina pubblica, può esporre dettagli tecnici e compromettere la visualizzazione.

Nel sito operativo verifico che:

gli errori non siano mostrati nel frontend;
i log non siano pubblicamente accessibili;
i file di registro non crescano senza limiti;
le informazioni sensibili non vengano registrate;
il debug venga attivato soltanto quando necessario.

Non Controllare i Permessi di File e Directory

I permessi determinano chi può leggere, modificare o eseguire file e cartelle.

Permessi eccessivamente aperti possono consentire modifiche non previste. Permessi troppo restrittivi possono invece impedire aggiornamenti, caricamenti e operazioni legittime.

Il valore corretto dipende dalla configurazione del server e non dovrebbe essere applicato copiando indicazioni generiche senza conoscere l’ambiente.

Durante il controllo verifico soprattutto:

file di configurazione;
directory dei caricamenti;
cartelle dei plugin;
cartelle dei temi;
file di log;
backup conservati sul server;
file temporanei.

Lasciare Accessibile la Modifica dei File dall’Amministrazione

WordPress può permettere agli amministratori di modificare file di tema e plugin direttamente dal pannello.

Questa funzione può essere pericolosa perché un account amministrativo compromesso potrebbe utilizzarla per inserire codice.

Nei progetti in cui non è necessaria, preferisco impedire la modifica dei file dall’area amministrativa e gestire gli interventi attraverso procedure controllate.

La disattivazione dell’editor non impedisce ogni possibile modifica, ma elimina uno strumento facilmente accessibile dall’interno di WordPress.

Non Proteggere il File di Configurazione

Il file di configurazione contiene informazioni essenziali, tra cui i dati necessari per collegarsi al database e altre impostazioni del sito.

Deve essere protetto attraverso:

permessi corretti;
configurazione adeguata del server;
assenza di copie pubbliche;
nessun invio tramite strumenti non sicuri;
accesso limitato agli amministratori tecnici;
gestione controllata delle modifiche.

Le credenziali non dovrebbero essere copiate in documenti condivisi, messaggi o file lasciati nell’area pubblica del sito.

Conservare Backup nella Cartella Pubblica

Alcuni strumenti creano archivi contenenti file e database e li salvano all’interno dello spazio web.

Se questi file sono raggiungibili attraverso un indirizzo pubblico, possono esporre:

database completo;
utenti;
impostazioni;
contenuti non pubblici;
credenziali presenti nei file;
plugin e temi;
informazioni personali.

I backup devono essere conservati in una posizione protetta, preferibilmente separata dal server principale.

La disponibilità di una copia non deve creare una nuova vulnerabilità.

Considerare Valido un Backup Mai Verificato

Un backup è realmente utile soltanto quando può essere ripristinato.

Tra i problemi più frequenti ci sono:

database mancante;
cartella dei media incompleta;
archivio danneggiato;
copia troppo vecchia;
backup conservato sullo stesso server compromesso;
procedura di ripristino sconosciuta;
spazio insufficiente;
esclusioni non documentate.

La strategia deve prevedere copie automatiche, conservazione adeguata e verifiche periodiche.

Non basta vedere un messaggio che indica il completamento dell’operazione.

Proteggere il Sito ma Dimenticare le Email

Le caselle email vengono spesso utilizzate per:

recuperare password;
ricevere notifiche;
approvare accessi;
gestire ordini;
ricevere richieste;
controllare domini e servizi;
attivare licenze.

Se l’email dell’amministratore viene compromessa, può diventare possibile recuperare l’accesso a WordPress e ad altri servizi collegati.

Password uniche e autenticazione a due fattori devono quindi essere applicate anche alle caselle principali.

Non Proteggere i Moduli

I moduli pubblici possono essere utilizzati per inviare spam, file, richieste automatizzate o contenuti non previsti.

Controllo:

validazione dei campi;
sanificazione dei dati;
limiti di invio;
protezione antispam;
tipi di file accettati;
dimensione degli allegati;
destinatari delle notifiche;
dati salvati nel database;
messaggi di errore;
permessi necessari.

Un modulo non deve considerare affidabili i dati soltanto perché provengono da una pagina del sito.

Consentire Caricamenti Senza Controlli Adeguati

Le funzioni di caricamento richiedono particolare attenzione.

Devono controllare:

tipo di file;
estensione;
dimensione;
nome;
contenuto dichiarato;
directory di destinazione;
utente autorizzato;
possibilità di esecuzione;
accessibilità pubblica.

Limitarsi a controllare l’estensione visibile nel nome del file può non essere sufficiente.

Quando la funzione non è necessaria, è preferibile non consentire caricamenti pubblici.

Lasciare API e Integrazioni Non Più Utilizzate

Nel tempo un sito può accumulare:

chiavi API;
token;
webhook;
password applicative;
integrazioni con CRM;
collegamenti a servizi di marketing;
automazioni;
account tecnici.

Quando una funzione viene rimossa, le relative credenziali possono restare attive.

Durante la manutenzione verifico quali integrazioni siano ancora necessarie e revoco quelle non più utilizzate.

Lasciare Pubblico l’Ambiente di Staging

Lo staging viene utilizzato per provare aggiornamenti, modifiche e nuove funzioni.

Può contenere una copia completa del sito, comprese informazioni che non dovrebbero essere pubblicamente accessibili.

Un ambiente di test deve essere protetto attraverso:

autenticazione;
limitazione degli accessi;
blocco dell’indicizzazione;
credenziali differenti;
rimozione quando non più necessario;
disattivazione delle email reali;
protezione dei dati personali.

Impedire l’indicizzazione non equivale a impedire l’accesso. Un ambiente riservato deve essere realmente protetto.

Copiare Dati Reali in Ambienti di Test Senza Necessità

Per riprodurre correttamente un sito può essere utile utilizzare dati simili a quelli reali. Non sempre è necessario copiare informazioni personali complete.

Negli ambienti di test valuto la possibilità di:

anonimizzare utenti;
rimuovere ordini e richieste;
sostituire email;
eliminare credenziali;
disattivare pagamenti;
bloccare notifiche;
usare dati dimostrativi.

Più copie esistono, maggiore diventa il numero di ambienti da proteggere.

Non Utilizzare HTTPS in Tutto il Sito

HTTPS protegge la comunicazione tra browser e server.

Non dovrebbe essere applicato soltanto alla schermata di accesso o al pagamento.

Controllo che:

tutte le pagine utilizzino HTTPS;
HTTP venga reindirizzato correttamente;
non siano presenti contenuti misti;
canonical e sitemap utilizzino HTTPS;
cookie e sessioni siano gestiti correttamente;
il certificato venga rinnovato;
le integrazioni utilizzino indirizzi sicuri.

HTTPS non risolve vulnerabilità di plugin o password deboli, ma è un livello fondamentale della protezione.

Non Controllare le Modifiche ai File

Un sito compromesso può contenere file nuovi oppure modifiche inserite in componenti esistenti.

I punti da verificare comprendono:

file principali di WordPress;
plugin;
temi;
cartella dei caricamenti;
file di configurazione;
attività programmate;
file nascosti;
codice aggiunto nei template;
script caricati da domini esterni.

Il confronto con versioni originali e il monitoraggio dell’integrità possono aiutare a individuare modifiche inattese.

Controllare Soltanto i File e Non il Database

Un problema può essere presente anche nel database.

Controllo la possibile presenza di:

utenti amministratori sconosciuti;
contenuti inseriti automaticamente;
link nascosti;
script nelle opzioni;
widget modificati;
attività programmate;
redirect indesiderati;
impostazioni alterate;
codice nei metadati;
account applicativi non riconosciuti.

Ripristinare soltanto i file può non eliminare una modifica salvata nel database.

Ignorare Utenti Amministratori Sconosciuti

Durante un controllo verifico sempre l’elenco degli utenti con privilegi elevati.

Un account sospetto può utilizzare:

un nome simile a quello di un amministratore reale;
un indirizzo email poco riconoscibile;
un nome generico;
una data di creazione recente;
un ruolo modificato direttamente nel database.

Prima di eliminare un utente verifico la sua origine e l’eventuale relazione con plugin, integrazioni o servizi tecnici.

Non Registrare le Attività Amministrative

Quando più persone gestiscono il sito, un registro delle attività può aiutare a capire:

chi ha modificato una pagina;
chi ha installato un plugin;
chi ha cambiato un’impostazione;
chi ha creato un utente;
quando è avvenuto un accesso;
quale componente è stato aggiornato;
quando è comparso un problema.

Il registro deve essere proporzionato e non dovrebbe raccogliere informazioni sensibili inutili.

Lo scopo è facilitare diagnosi e tracciabilità, non registrare indiscriminatamente qualsiasi dato.

Ignorare le Notifiche Importanti

Un sistema che invia troppe notifiche porta spesso a ignorarle tutte.

Le segnalazioni devono distinguere tra:

eventi informativi;
aggiornamenti disponibili;
accessi sospetti;
modifiche ai file;
backup falliti;
certificati in scadenza;
errori ripetuti;
componenti vulnerabili;
problemi del server.

Configuro le notifiche in modo che raggiungano una persona responsabile e contengano informazioni utili per decidere cosa fare.

Non Avere una Procedura in Caso di Compromissione

Quando viene rilevato un problema, interventi casuali possono cancellare informazioni utili o lasciare attiva la causa originale.

Una procedura dovrebbe prevedere:

limitare l’accesso al sito quando necessario;
conservare le informazioni utili all’analisi;
identificare account e componenti coinvolti;
cambiare le credenziali compromesse;
aggiornare o sostituire i componenti vulnerabili;
controllare file e database;
verificare backup e ripristino;
revocare token e chiavi;
monitorare il sito dopo la pulizia;
documentare la causa e le correzioni.

Ripristinare un backup senza eliminare il punto di accesso può portare a una nuova compromissione.

Un Esempio Pratico di Problema Invisibile

Un sito aziendale può continuare a mostrare correttamente pagine, moduli e immagini. L’unico segnale visibile può essere una variazione improvvisa dei risultati di ricerca.

Durante il controllo può emergere che:

un vecchio plugin non è più aggiornato;
è stato creato un amministratore sconosciuto;
alcune pagine contengono collegamenti nascosti;
il comportamento cambia in base al dispositivo;
il codice sospetto è salvato nel database;
i backup disponibili contengono già il problema.

In una situazione simile non basta aggiornare WordPress o eliminare la pagina visibile.

È necessario individuare il punto di accesso, rimuovere le modifiche, controllare gli account, cambiare le credenziali e monitorare nuovamente il sito.

Il Mio Metodo per Controllare la Sicurezza di WordPress

Durante un controllo seguo una procedura ordinata:

Verifico WordPress, tema e plugin.
Individuo componenti inutilizzati o abbandonati.
Controllo versione di PHP e ambiente hosting.
Analizzo utenti, ruoli e accessi.
Verifico password, autenticazione e recupero account.
Controllo backup e possibilità di ripristino.
Analizzo file, database e attività programmate.
Verifico permessi e configurazioni principali.
Controllo moduli, caricamenti e integrazioni.
Analizzo staging e copie del sito.
Controllo log e notifiche.
Rimuovo accessi e componenti non necessari.
Documento gli interventi eseguiti.
Programmo controlli successivi.

La procedura cambia in base al tipo di sito, ma il principio rimane lo stesso: ridurre gli accessi, mantenere aggiornati i componenti e verificare periodicamente ciò che è realmente presente nel progetto.

Ridurre gli Errori di Sicurezza WordPress

Gli errori di sicurezza WordPress più comuni derivano spesso da abitudini apparentemente innocue: rimandare gli aggiornamenti, condividere gli account, mantenere plugin inutilizzati o considerare valido un backup mai provato.

La protezione non dipende da un singolo intervento. Richiede un insieme di controlli su WordPress, hosting, utenti, file, database, email e servizi collegati.

Ogni funzione aggiunta al sito deve avere un motivo preciso, un responsabile e una procedura di manutenzione.

Un sito sicuro non è un sito nel quale non può accadere nulla. È un progetto nel quale i rischi vengono ridotti, gli accessi sono controllati e gli eventuali problemi possono essere individuati e gestiti rapidamente.

Aggiornamenti regolari, privilegi limitati, password uniche, autenticazione a due fattori e backup verificati rappresentano una base molto più solida rispetto all’installazione casuale di numerosi strumenti di protezione.