Sicurezza WordPress: Da dove iniziare per proteggere il tuo sito

La sicurezza WordPress in numeri

I dati che seguono provengono dai report annuali di Wordfence, Patchstack e Sucuri — le tre organizzazioni di riferimento per la sicurezza WordPress a livello globale. I loro report vengono citati come fonti primarie nel settore e sono aggiornati annualmente.

Cosa significano questi numeri nella pratica? Che la minaccia è strutturale, non episodica. Ventidue nuove vulnerabilità al giorno nell’ecosistema WordPress significa che anche un sito ben configurato oggi può diventare vulnerabile domani, per colpa di un plugin che installi la prossima settimana. Non è un motivo di panico — è un motivo per costruire una strategia di sicurezza che non dipenda dalla fortuna o dall’assenza di attacchi, ma dalla capacità di rilevarli e rispondervi rapidamente.

Perché WordPress viene attaccato così spesso?

WordPress alimenta oltre il 43% di tutti i siti web esistenti. Per un attaccante, questo significa che uno script automatizzato scritto una volta può essere usato contro milioni di bersagli potenziali. Non serve prendere di mira qualcuno in modo specifico — si scansiona la rete, si trovano le installazioni vulnerabili, si applica l’exploit. Il rapporto sforzo/risultato è così favorevole che nel 2024 Wordfence ha bloccato 55 miliardi di tentativi di attacco tramite password su siti WordPress. Non perché qualcuno ti abbia scelto — perché sei su una piattaforma abbastanza diffusa da renderti statisticamente interessante.

Il paradosso è che quella stessa popolarità è anche la sua difesa più forte. Il core di WordPress è sviluppato e monitorato da centinaia di sviluppatori in tutto il mondo — ogni vulnerabilità scoperta viene analizzata, discussa pubblicamente e patchata in tempi rapidi. Nel 2024 sono state scoperte solo 7 vulnerabilità nel core, nessuna abbastanza grave da costituire una minaccia diffusa (fonte: Patchstack). WordPress non è un bersaglio facile perché è mal fatto — è un bersaglio frequente perché è ovunque. La differenza è sostanziale.

Il punto d’ingresso è quasi sempre altrove. Ecco i tre vettori che vedo tornare su ogni sito compromesso che mi viene portato.

Plugin e temi non aggiornati

Il meccanismo è semplice e per questo efficace: uno sviluppatore scopre una vulnerabilità in un plugin, la corregge e rilascia un aggiornamento. Nel momento in cui l’aggiornamento è pubblico, la vulnerabilità è documentata — e tutti i siti che non hanno ancora aggiornato sono bersagli identificati. I bot iniziano a scansionare entro ore. Non serve un hacker: basta uno script automatizzato che cerca la versione vulnerabile e applica l’exploit già scritto da qualcun altro.

Nel 2024 sono state scoperte 7.966 nuove vulnerabilità nell’ecosistema WordPress — 22 nuove ogni giorno. Il 96% riguardava plugin, il 4% temi. Nessuna nel core. Ancora più preoccupante: il 35% di queste vulnerabilità è arrivato alla divulgazione pubblica senza una patch disponibile (fonte: Patchstack e Wordfence). Ho visto siti con plugin non aggiornati da due anni con decine di CVE documentati — in quei casi la domanda non è se il sito è stato compromesso, ma quante volte.

Credenziali deboli e attacchi brute force

La pagina wp-login.php è pubblica su ogni installazione WordPress standard. Gli attacchi brute force — che provano migliaia di combinazioni username e password al secondo — sono automatizzati e continui. Un account con username ‘admin’ (il default storico di WordPress) e una password semplice può essere violato in pochi minuti. Non è un’esagerazione: i log di un sito esposto mostrano centinaia di tentativi di login ogni ora, 24 ore su 24.

La buona notizia è che è anche la minaccia più semplice da neutralizzare. Limitare i tentativi di accesso, abilitare l’autenticazione a due fattori (2FA) e cambiare l’URL di login predefinito sono tre misure che richiedono meno di un’ora e rendono gli attacchi brute force praticamente inutili.

Configurazione lasciata ai valori di default

WordPress esce dalla scatola con una configurazione pensata per funzionare, non per essere sicura. Permessi file troppo permissivi, wp-config(.)php accessibile dalla root pubblica, XML-RPC abilitato anche se non lo usi, prefissi delle tabelle del database lasciati al valore predefinito wp_, editor di file abilitato dalla dashboard — ognuno di questi elementi è un vantaggio per chi sa cosa cercare. Anche la versione PHP del server è un fattore spesso trascurato: versioni obsolete non ricevono patch di sicurezza e rimangono esposte a vulnerabilità note.

C’è anche un fattore spesso ignorato: la qualità dell’hosting. Su un hosting condiviso mal configurato, una vulnerabilità in un altro sito sullo stesso server può essere usata per accedere al tuo — è quello che si chiama cross-site contamination. Non è un caso teorico: è una delle cause di reinfection più frustranti perché anche dopo una bonifica perfetta il sito viene reinfettato attraverso un vicino di server che non hai mai visto.

1. Accessi non autorizzati

Gli attacchi brute force contro wp-login.php sono la minaccia più comune e, per fortuna, la più semplice da bloccare. Limitare i tentativi di accesso con un plugin dedicato — applicando il rate limiting per IP — abilitare il 2FA per tutti gli account admin e cambiare l’URL di login predefinito sono tre interventi che richiedono meno di un’ora e che da soli eliminano la grande maggioranza di questi attacchi. Aggiungere un Web Application Firewall (WAF) come Wordfence o Cloudflare blocca i tentativi di SQL injection, cross-site scripting (XSS) e attacchi DDoS ancora prima che raggiungano WordPress, riducendo anche il carico sul server.

2. Malware e backdoor

Quando un attaccante riesce ad entrare, il primo obiettivo non è fare danni visibili — è installarsi in modo permanente. Una backdoor è un file PHP nascosto che permette di rientrare nel sito anche dopo che la vulnerabilità originale è stata chiusa. Può stare nella cartella mu-plugins (caricata automaticamente senza apparire nella lista plugin), in un tema inattivo, in una cartella nascosta con il punto davanti. Il malware nel frattempo lavora: reindirizza i visitatori, inietta link spam, manda email, ospita pagine di phishing. A volte tutto questo avviene in modo condizionale — solo per i visitatori che arrivano da Google, solo da mobile — per restare invisibile il più a lungo possibile.

Rilevare il malware richiede strumenti specifici come Wordfence o Sucuri Scanner, ma in alcuni casi — quando il codice è offuscato con eval(base64_decode()) — la ricerca manuale è l’unico modo per trovarlo. È per questo che i plugin di sicurezza da soli non bastano sempre.

3. Vulnerabilità nei plugin e nei temi

Non tutti i plugin vengono mantenuti con la stessa cura. Alcuni vengono abbandonati dagli sviluppatori dopo pochi mesi, restando online nel repository ufficiale con vulnerabilità note e senza patch. Altri arrivano da marketplace non verificati o, peggio, come versioni nulled — copie piratate di plugin premium che contengono backdoor già installate prima ancora che tu le attivi.

La regola pratica che applico: nessun plugin non aggiornato da più di sei mesi dovrebbe stare su un sito in produzione. Prima di installare qualsiasi plugin o tema, verifico l’ultima data di aggiornamento, il numero di installazioni attive e se lo sviluppatore risponde alle segnalazioni di sicurezza. Strumenti come WPScan e Patchstack permettono di monitorare automaticamente le vulnerabilità note nei plugin installati e ricevere avvisi quando qualcosa è a rischio. Per la scansione attiva, Wordfence e Sucuri sono i più diffusi, ma esistono valide alternative come MalCare, iThemes Security (ora Solid Security) e WP Cerber — la scelta dipende dalla configurazione specifica del sito.

4. Hardening e configurazione

L’hardening di WordPress è la pratica di modificare la configurazione predefinita per ridurre la superficie di attacco. Non è un’operazione una tantum — è un insieme di interventi che si stratificano: permessi corretti sui file (644 per i file, 755 per le cartelle, 600 per wp-config(.)php), XML-RPC disabilitato se non necessario, editor di file disabilitato dalla dashboard, HTTP security headers configurati, ruoli utente assegnati con il principio del privilegio minimo, versione PHP aggiornata all’ultima release stabile.

Un elemento spesso sottovalutato è l’activity log — il registro di ogni azione eseguita sul sito. Plugin come WP Activity Log o la funzione di audit log di Wordfence permettono di vedere chi ha fatto cosa e quando: un nuovo utente admin creato alle 3 di notte è un segnale inequivocabile. Allo stesso modo, avere un ambiente di staging separato dove testare aggiornamenti prima di portarli in produzione riduce drasticamente il rischio di rompere il sito durante la manutenzione.

Ogni intervento da solo vale poco — insieme riducono drasticamente le possibilità che un attaccante, anche dopo essere entrato, possa fare danni significativi o installare una backdoor persistente.

La sicurezza WordPress non si costruisce installando tutto quello che esiste — si costruisce nell’ordine giusto, partendo da quello che elimina il rischio maggiore con il minore sforzo. Il principio è semplice: inizia dalle misure che proteggono i punti più esposti agli attacchi automatizzati, poi passa a quelle che richiedono più tempo o competenze. Un bot non distingue tra un sito da 50 visite al giorno e uno da 50.000 — testa le stesse vulnerabilità su entrambi. Le prime tre misure in lista (backup, 2FA, limitare i login) eliminano già la stragrande maggioranza degli attacchi automatizzati.

 L’approccio consigliato non è implementare tutto insieme. Inizia dal backup esterno verificato e dal 2FA — richiedono meno di un’ora e cambiano radicalmente il profilo di rischio del sito. Poi aggiungi il firewall e il monitoraggio delle vulnerabilità. Il resto — hardening avanzato, permessi file, staging — viene dopo, quando le basi sono solide. Una sicurezza costruita per strati nel tempo è più efficace e più sostenibile di un intervento massiccio fatto tutto in una volta.

Se sospetti che il tuo sito WordPress sia stato compromesso, il tempo è un fattore critico. Più a lungo un sito rimane infetto, maggiore è il rischio che Google lo inserisca nella sua blacklist — con perdita di traffico organico, avvisi di malware per i visitatori e potenziali implicazioni GDPR se il malware raccoglie dati degli utenti.

I segnali visibili più comuni: reindirizzamenti verso altri siti (spesso solo da mobile o da Google), contenuti estranei nelle pagine, avvisi di sicurezza in Google Search Console, email di spam inviate dal tuo dominio, impossibilità di accedere alla dashboard. Ma gli attacchi più sofisticati restano invisibili per settimane — il sito sembra normale, i visitatori vengono reindirizzati in modo condizionale, il malware lavora silenzioso. Per questo il monitoraggio preventivo vale più della reazione.

Se il malware continua a tornare dopo la pulizia o la situazione ti sembra fuori controllo, il problema ha quasi sempre radici più profonde — una backdoor non rimossa o una vulnerabilità originale mai chiusa. In questi casi è il momento di valutare un intervento di assistenza WordPress professionale — dove la bonifica viene eseguita nell’ordine corretto, con identificazione della causa radice e hardening finale.