Sicurezza WordPress: come proteggere il tuo sito davvero

Un sito WordPress non si buca perché “WordPress è insicuro”. Si buca quasi sempre per tre motivi molto banali: un plugin non aggiornato con una vulnerabilità nota, una password debole su un utente amministratore, un hosting condiviso che non isola gli ambienti. Il resto, i plugin “all-in-one security” con dashboard rassicuranti, i firewall lato applicativo che promettono di bloccare “il 99% degli attacchi”, arriva molto dopo, e a volte serve a dare un’illusione di protezione più che protezione vera.

Questa guida mette in fila le misure che contano davvero, nell’ordine in cui vanno affrontate, con indicazioni operative precise: cosa installare, quali file modificare, quali snippet aggiungere, quali configurazioni fare. Se gestisci un sito WordPress professionale o segui clienti che lo fanno, ecco cosa dovrebbe esserci sopra.

Prima di tutto: l’hosting fa metà del lavoro

La sicurezza di un sito WordPress inizia sotto il sito, non dentro. Un hosting condiviso da 30 euro l’anno mette il tuo sito nella stessa macchina di altre centinaia di installazioni, spesso non aggiornate. Se una di quelle viene compromessa, il rischio di contagio laterale è concreto: attacchi tipo symlink, permessi permissivi sui file, database accessibili tra utenti dello stesso pool.

La prima misura di sicurezza vera è scegliere un hosting che isoli gli ambienti: server dedicato, VPS gestito, o hosting managed WordPress con containerizzazione reale. Il costo mensile parte da 20-40 euro per progetti piccoli e sale in base a traffico e risorse. È lo stesso principio del sito web economico che finisce per costare di più: risparmi sull’infrastruttura, paghi in incidenti.

Cosa chiedere all’hosting prima di firmare:

• Isolamento dei processi tra account (container, non chroot generico)
• PHP aggiornato alla versione supportata corrente (nel 2026, PHP 8.3 o 8.4)
• Certificato SSL automatico con rinnovo gestito (Let’s Encrypt via ACME o certificato commerciale)
• Backup giornalieri off-site con retention di almeno 14-30 giorni
• Accesso SSH e SFTP, non solo FTP
• Firewall a livello di rete e mitigazione DDoS di base

Aggiornamenti: la misura che previene la maggior parte degli attacchi

La maggioranza dei siti WordPress compromessi lo è tramite vulnerabilità note in plugin o temi non aggiornati. Non exploit sofisticati: falle documentate pubblicamente, con proof-of-concept in circolazione, che i bot scansionano in automatico. Il rimedio è banale: aggiornare.

La strategia operativa è duplice. Per il core WordPress abilita gli aggiornamenti minori automatici (di default lo sono già dalla 3.7); per major, plugin e temi imposta un ciclo di manutenzione controllato, non automatico su sito di produzione. La ragione è pratica: un aggiornamento plugin può rompere il sito, e se non hai testato prima ti trovi il frontend rotto senza sapere quale versione ha causato il problema.

Configurazione consigliata nel file wp-config.php:

// Aggiornamenti minori automatici (default, ma esplicito)
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Disabilita editor file da dashboard (impedisce modifica plugin/temi via wp-admin)
define( 'DISALLOW_FILE_EDIT', true );

// Forza installazioni/aggiornamenti via SSH/SFTP e non via wp-admin
define( 'DISALLOW_FILE_MODS', false ); // metti a true solo se gestisci tutto via CI/CD

Il flusso operativo tipico è: ambiente di staging che replica la produzione, aggiornamento e test sullo staging, deploy in produzione dopo verifica. Se il sito è mission-critical, questo ciclo va fatto ogni 2-4 settimane. È parte dei costi di manutenzione reali di un sito che molti imprenditori scoprono solo dopo il primo incidente.

Password, utenti e autenticazione: dove passa il 90% degli attacchi bruteforce

Ogni installazione WordPress esposta su internet riceve tentativi di login automatici su /wp-login.php e /xmlrpc.php. Sono bot che provano combinazioni utente/password su liste enormi. Se hai un utente chiamato “admin” con password “Azienda2024”, ci mettono poco a entrare.

Le misure che contano, in ordine:

1. Nessun utente si chiama “admin”. Crea un nuovo utente amministratore con nome non prevedibile, poi elimina “admin” attribuendone i contenuti al nuovo utente.
2. Password lunghe generate a caso. Minimo 20 caratteri, gestite in un password manager (1Password, Bitwarden). Le password “complesse ma memorizzabili” sono più deboli di quelle lunghe e casuali.
3. Autenticazione a due fattori obbligatoria per tutti gli amministratori e gli editor. Plugin: Two Factor (ufficiale del team WordPress) o WP 2FA. Metodo consigliato: app TOTP (Google Authenticator, Authy), non SMS.
4. Limita i tentativi di login. Plugin: Limit Login Attempts Reloaded. Blocca IP dopo 3-5 tentativi falliti, con lockout progressivo.
5. Disabilita XML-RPC se non lo usi (quasi mai serve nel 2026). Snippet nel functions.php del tema figlio o in un plugin custom:

// Disabilita XML-RPC completamente
add_filter( 'xmlrpc_enabled', '__return_false' );

// Blocca l'endpoint anche a livello HTTP (aggiungi al .htaccess)
// <Files xmlrpc.php>
//   Require all denied
// </Files>

Per la pagina di login, valuta se spostarla da /wp-admin e /wp-login.php a un percorso custom con il plugin WPS Hide Login. Non è sicurezza vera (è security through obscurity), ma taglia il 95% del traffico bot che scansiona URL standard, e alleggerisce il server.

Plugin di sicurezza: quali servono davvero e quali no

Il mercato dei plugin di sicurezza WordPress è affollato e ambiguo. Wordfence, Sucuri, iThemes Security (ora Solid Security), All In One WP Security, Jetpack Security. Molti offrono dashboard rassicuranti con “scansioni malware”, “firewall applicativo”, “reputation IP”. Alcune funzioni sono utili, altre sono teatro di sicurezza.

Cosa serve davvero da un plugin di sicurezza:

• Rate limiting sui login, utile se non lo fa già l’hosting o un firewall a monte
• Scansione file per integrità, controlla se i file core WordPress hanno checksum diversi da quelli ufficiali
• Notifica modifiche a file critici (wp-config, .htaccess, functions.php)
• Log degli accessi amministrativi, chi ha fatto cosa, quando

Cosa NON serve o è ridondante:

• Firewall applicativo (WAF) del plugin: un WAF vero sta a monte del sito (Cloudflare, BunkerWeb, il firewall dell’hosting), non dentro PHP che gira dopo che la richiesta è già arrivata al server
• Scansione malware “in tempo reale”: consuma CPU e spesso trova falsi positivi; una scansione notturna programmata basta
• “Blocco paesi” generico: se non vendi in un paese, blocca l’accesso a wp-admin da quel paese, non tutto il sito

La configurazione minima praticabile: Wordfence in versione free per scansione integrità e monitor login, oppure Solid Security configurato in modalità essenziale. Aggiungere Cloudflare (piano free) davanti al sito come CDN e primo strato di filtraggio è quasi sempre una buona idea.

Backup: la sola cosa che ti salva quando tutto il resto fallisce

Nessuna misura di sicurezza è infallibile. Prima o poi qualcosa succede: un plugin viene compromesso a monte (supply chain attack), un dipendente clicca su un link di phishing, un aggiornamento va male. In quel momento, l’unica cosa che conta è la qualità del backup.

Regola operativa: backup 3-2-1. Tre copie dei dati, su due supporti diversi, di cui una off-site. In pratica:

1. Backup dell’hosting, quello incluso nel piano, con retention di 14-30 giorni
2. Backup automatico esterno, plugin come UpdraftPlus o Duplicator Pro verso Amazon S3, Google Drive, Dropbox o storage compatibile
3. Backup manuale periodico, snapshot completo (file + database) scaricato localmente ogni 1-3 mesi, conservato offline

Frequenza consigliata: database giornaliero, file settimanale (o giornaliero se il sito ha upload frequenti tipo e-commerce). Il backup non testato non esiste: almeno una volta ogni sei mesi ripristina il backup su un ambiente di staging e verifica che funzioni. Un backup corrotto che scopri il giorno del disastro è peggio di nessun backup.

Snippet per esclusioni utili in UpdraftPlus (dalla dashboard, non da codice): escludi le cartelle wp-content/cache, wp-content/uploads/wpo-cache, e le cartelle di backup di altri plugin per evitare backup nidificati che gonfiano l’archivio.

Hardening del file system e configurazioni server

Alcune misure vanno fatte una volta e poi dimenticate. Sono piccole, ma tagliano intere classi di attacchi.

Permessi file corretti (via SSH):

# Cartelle a 755
find /path/to/wordpress -type d -exec chmod 755 {} \;

# File a 644
find /path/to/wordpress -type f -exec chmod 644 {} \;

# wp-config.php a 600 (o 640 se il webserver ha bisogno di leggerlo)
chmod 600 /path/to/wordpress/wp-config.php

Proteggi wp-config.php e .htaccess a livello di webserver. In .htaccess aggiungi:

<Files wp-config.php>
  Require all denied
</Files>

<Files .htaccess>
  Require all denied
</Files>

# Disabilita esecuzione PHP nella cartella uploads
<Directory /path/to/wordpress/wp-content/uploads/>
  <FilesMatch "\.(php|phtml|php[0-9])$">
    Require all denied
  </FilesMatch>
</Directory>

Nascondi la versione di WordPress dai meta tag e dagli header:

// Rimuove il meta generator
remove_action( 'wp_head', 'wp_generator' );

// Rimuove la versione da script e style
add_filter( 'style_loader_src', function( $src ) {
    return remove_query_arg( 'ver', $src );
});
add_filter( 'script_loader_src', function( $src ) {
    return remove_query_arg( 'ver', $src );
});

Prefisso tabelle database diverso da wp_: si imposta in fase di installazione (in wp-config.php: $table_prefix = 'wp_xy8k_';). Cambiarlo dopo è possibile ma richiede uno script dedicato e mette a rischio l’installazione se sbagli. Vale la pena farlo su installazioni nuove, non su siti esistenti che funzionano.

Monitoraggio e cosa fare se il sito viene compromesso

La sicurezza non è solo prevenzione, è anche detection e response. Un sito compromesso può restare tale per settimane prima che qualcuno se ne accorga. I segnali tipici: rallentamenti improvvisi, comparsa di pagine spam nell’indice Google (cerca site:tuosito.it e vedi cosa esce), avvisi di Google Search Console su “software dannoso”, email in uscita che finiscono in spam.

Monitoraggio minimo consigliato:

• Google Search Console attiva e collegata al sito, controlla la sezione “Problemi di sicurezza”
• Uptime monitor esterno (UptimeRobot, StatusCake) che controlli ogni 5 minuti
• Alert su modifiche file dal plugin di sicurezza scelto
• Report periodico mensile con log accessi, tentativi di login bloccati, aggiornamenti applicati

Se scopri una compromissione, la sequenza è: metti il sito in maintenance, cambia tutte le password (WordPress, database, hosting, FTP), ripristina l’ultimo backup pulito noto (non il più recente, se il più recente contiene già la compromissione), aggiorna tutto, poi fai un’analisi forense per capire il vettore d’ingresso. Senza capire come sono entrati, verranno reinstallati nel giro di giorni. Molti siti che sembrano “belli fuori ma non funzionano” hanno alle spalle proprio questo tipo di storia, ed è uno dei motivi per cui tanti siti di PMI italiane non portano clienti e nessuno capisce perché.

Checklist finale di verifica

Prendi il tuo sito (o quello di un cliente) e passa questa lista. Se hai spunte vuote, sai dove intervenire.

• Hosting con isolamento reale degli ambienti e PHP aggiornato
• SSL attivo su tutto il sito, con redirect 301 da HTTP a HTTPS
• Nessun utente si chiama “admin”
• Tutti gli amministratori usano password lunghe e 2FA
• Limite tentativi di login attivo
• XML-RPC disabilitato se non necessario
• Core, plugin e temi aggiornati (major manuali, minor automatici)
• Plugin non utilizzati disinstallati (non solo disattivati)
• Editor file da dashboard disabilitato (DISALLOW_FILE_EDIT)
• Backup automatici giornalieri, di cui almeno uno off-site
• Backup testato con ripristino su staging negli ultimi 6 mesi
• Permessi file corretti (755/644, wp-config a 600)
• Esecuzione PHP disabilitata in /uploads
• Cloudflare o WAF a monte del sito
• Google Search Console configurata e monitorata
• Uptime monitor esterno attivo

Domande frequenti

Wordfence gratuito basta per proteggere un sito WordPress?

Per un sito piccolo o medio, la versione gratuita di Wordfence copre l’essenziale: scansione integrità file, monitor login, blocco IP malevoli con signature aggiornate ogni 30 giorni (la versione a pagamento ha aggiornamento in tempo reale). Non basta da sola: va combinata con aggiornamenti regolari, backup, 2FA e un hosting decente. Il plugin è uno strato, non l’intera architettura.

Meglio Wordfence o Cloudflare davanti al sito?

Sono cose diverse e complementari. Cloudflare sta prima del tuo server e filtra il traffico a livello di rete: intercetta bot, DDoS e attacchi noti prima che tocchino WordPress. Wordfence sta dentro WordPress e vede cose che Cloudflare non vede (integrità file, tentativi login sul sito). Su siti professionali si usano entrambi, con Cloudflare come primo strato e un plugin di sicurezza come secondo.

Ogni quanto vanno aggiornati i plugin WordPress?

Gli aggiornamenti di sicurezza vanno applicati entro pochi giorni dalla pubblicazione. Per gli aggiornamenti di funzionalità (non critici), un ciclo di 2-4 settimane su staging seguito da deploy in produzione è ragionevole. Non attivare l’auto-update di tutti i plugin su un sito in produzione senza staging: un aggiornamento rotto sabato notte può lasciarti offline fino a lunedì.

Serve davvero cambiare il prefisso delle tabelle database da wp_ a qualcos’altro?

È utile su installazioni nuove, meno su siti esistenti. Il vantaggio è marginale: rende meno banali certi attacchi SQL injection automatizzati che assumono il prefisso standard. Non è una misura decisiva. Se stai installando ora, mettilo random; se il sito è vivo da anni e funziona, non toccarlo per questo motivo, il rischio di rompere qualcosa supera il beneficio.

Cosa faccio se scopro che il sito è stato hackerato?

Nell’ordine: metti il sito in maintenance mode, cambia tutte le password (WordPress admin, database, hosting, FTP/SSH), scarica un backup dello stato attuale per analisi, ripristina un backup precedente noto pulito, aggiorna tutto, cambia le chiavi salt in wp-config.php per forzare il logout di eventuali sessioni compromesse. Poi indaga il vettore d’ingresso: senza capire da dove sono entrati, torneranno.

Quanto costa mettere in sicurezza un sito WordPress esistente?

Dipende dallo stato di partenza. Su un sito ben tenuto, servono poche ore di configurazione (hardening, 2FA, backup). Su un sito trascurato con plugin obsoleti, temi nulled o già compromesso in passato, il lavoro di bonifica può richiedere una o due giornate, e a volte conviene ricostruire da zero. La manutenzione ordinaria mensile, con aggiornamenti testati e monitoraggio, parte da qualche centinaio di euro l’anno.

Il punto operativo

La sicurezza di WordPress non è un plugin che compri, è una serie di configurazioni e abitudini che metti in fila. Nell’ordine giusto: prima l’hosting, poi le utenze e l’autenticazione, poi gli aggiornamenti, poi i backup, poi il monitoraggio. Il plugin di sicurezza arriva dopo, e serve a coprire un pezzo, non a sostituire tutto il resto.

Se hai un sito in produzione e non hai mai passato una checklist come quella qui sopra, il momento giusto per farlo è adesso, non dopo il primo incidente. La differenza tra un sito compromesso e uno che regge si gioca quasi sempre su poche ore di configurazione mai investite.