Sicurezza WordPress per Agenzie: La Guida Definitiva [2026]

La Sicurezza WordPress Non È un Plugin. È un Processo.

Installi Wordfence. Attivi il firewall. Dormi tranquillo. Poi un sabato mattina il cliente ti chiama perché il sito mostra pagine di poker online al posto della homepage. Wordfence era attivo. Il backup era di 3 settimane fa. Buon weekend.

Questo scenario non è ipotetico. L’abbiamo vissuto (e risolto) più volte in 15 anni di gestione WordPress per agenzie e PA. Il punto non è che Wordfence non funziona. Funziona. Ma un plugin di sicurezza è un layer, non la soluzione.

La sicurezza WordPress per un’agenzia che gestisce 20-50 siti è un processo multi-livello: prevenzione, monitoraggio, risposta, e recovery. Questo articolo copre tutti e quattro.

I Numeri Reali degli Attacchi WordPress

Secondo il Sucuri Threat Report 2023:

• Il 60.04% dei siti WordPress hackerati non era aggiornato al momento dell’attacco
• Il 36.7% delle infezioni era dovuto a plugin vulnerabili (non al core WordPress)
• Il 56% delle backdoor usava file PHP nascosti nella directory uploads
• La reinfezione avviene nel 25% dei casi se la causa root non viene rimossa

WordPress è il CMS più attaccato al mondo perché è il più usato (43.5% dei siti web, W3Techs). Non perché è insicuro. È un bersaglio per probabilità, non per debolezza.

I 5 Layer della Sicurezza WordPress

Layer 1: Aggiornamenti (previene il 60% degli attacchi)

Il dato Sucuri è chiaro: 6 siti hackerati su 10 non erano aggiornati. L’aggiornamento è la singola azione con il ROI di sicurezza più alto.

Per un’agenzia con 30 siti, l’aggiornamento manuale non scala. Serve automazione con salvaguardie:

1. Aggiornamenti minor del core: automatici (WordPress lo fa già di default)
2. Aggiornamenti plugin: automatici per patch di sicurezza, manuali per major version
3. Aggiornamenti major: staging first, test, poi produzione

// Abilita auto-update per plugin con security fix
add_filter('auto_update_plugin', function($update, $item) {
    // Lista plugin critici: aggiorna sempre
    $critical = ['wordfence', 'wordpress-seo', 'woocommerce'];
    if (in_array($item->slug, $critical)) return true;
    
    // Per gli altri, aggiorna solo minor/patch
    return $update;
}, 10, 2);

Layer 2: Hardening del Server

Il 90% degli hosting condivisi ha configurazioni di sicurezza minime. Se gestisci il server (VPS, dedicato), questi sono i punti da blindare:

Nginx (o Apache):

# Blocca accesso a file sensibili
location ~* /\.(htaccess|htpasswd|ini|log|sh|sql)$ {
    deny all;
}

# Blocca esecuzione PHP nella directory uploads
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

# Blocca accesso a xmlrpc.php (vettore di attacco brute force)
location = /xmlrpc.php {
    deny all;
}

# Security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

PHP:

; php.ini - hardening
expose_php = Off
display_errors = Off
log_errors = On
disable_functions = exec,passthru,shell_exec,system,proc_open,popen
upload_max_filesize = 10M
max_execution_time = 30
session.cookie_httponly = 1
session.cookie_secure = 1

Layer 3: Autenticazione

Il brute force su /wp-login.php è l’attacco più comune. Un sito WordPress mediamente subisce centinaia di tentativi al giorno.

Le difese (cumulabili):

• 2FA obbligatoria per tutti gli admin. Plugin: WP 2FA o Wordfence Login Security. Non opzionale. Obbligatoria
• Limite tentativi login: Wordfence lo fa di default (20 tentativi → lockout 4 ore)
• Cambio URL login: plugin WPS Hide Login. Non è sicurezza reale (security through obscurity), ma riduce il rumore nei log del 95%
• Application Passwords: per le integrazioni API, usa le Application Passwords di WordPress invece delle credenziali principali

Layer 4: Monitoraggio

La sicurezza senza monitoraggio è come una serratura senza telecamera. Sai che c’è, ma non sai se qualcuno ci sta armeggiando.

• File integrity monitoring: Wordfence confronta i file del core, temi e plugin con le versioni originali. Se un file cambia senza aggiornamento, è un red flag
• Log di accesso: analizza chi accede a wp-admin, da dove, quando. L’AI può analizzare i pattern e identificare anomalie
• Malware scan: scansione settimanale dei file. Wordfence, Sucuri Scanner, o MalCare
• Uptime monitoring: un sito che va offline inaspettatamente potrebbe essere stato compromesso

Layer 5: Recovery

Quando (non se) succede, devi poter ripristinare in minuti, non in giorni:

• Backup giornaliero con retention di almeno 30 giorni (il malware può essere dormiente per settimane)
• Backup off-site: non sullo stesso server del sito. S3, Google Cloud, o altro provider
• Procedura di recovery documentata: chi fa cosa, in quale ordine. Non è il momento di improvvisare
• Canale di comunicazione emergenza: il cliente deve sapere entro 1 ora. Prepara il template della comunicazione prima che serva

Checklist Sicurezza per Agenzie (Copia e Usa)

Costi della Sicurezza vs Costi di un Breach

La prevenzione costa ~$130/sito/anno. Un singolo incident costa $800-5000+. La matematica è chiara.

FAQ

Wordfence o Sucuri?

Wordfence per chi gestisce il server (firewall a livello applicazione, scan file locale, ottimo per VPS). Sucuri per chi è su hosting condiviso (WAF cloud, CDN inclusa, cleanup garantito). Per un confronto dettagliato, leggi il nostro articolo dedicato.

WordPress è sicuro per l’e-commerce?

Sì, con la configurazione corretta. WooCommerce gestisce milioni di transazioni. Ma richiede: SSL obbligatorio, PCI compliance dell’hosting, 2FA su tutti gli account admin, e monitoraggio continuo. Non è diverso da qualsiasi piattaforma e-commerce: la sicurezza dipende dalla configurazione, non dal software.

Quanto spesso devo fare il backup?

Per siti con contenuto dinamico (blog attivi, e-commerce): backup giornaliero del database, settimanale dei file. Per siti statici (vetrina aziendale): settimanale è sufficiente. Retention: almeno 30 giorni. Il malware può essere dormiente per settimane prima di attivarsi.

Devo bloccare xmlrpc.php?

Sì, a meno che tu non usi servizi che lo richiedono (Jetpack, app WordPress mobile ufficiale, alcuni plugin di publishing remoto). xmlrpc.php è il vettore #1 per attacchi brute force amplificati (system.multicall) e DDoS. Bloccalo a livello server, non con un plugin.