Hardening WordPress: 25 Tecniche Avanzate per Blindare il Tuo Sito [2026]

L’hardening WordPress non è un’opzione quando gestisci siti in produzione per clienti. Nel 2025 sono state registrate 11.334 vulnerabilità nell’ecosistema WordPress, di cui il 91% nei plugin, con un tempo medio di sfruttamento di massa di sole 5 ore dalla divulgazione pubblica (fonte: Patchstack State of WordPress Security 2026). Un hardening sistematico è l’unica difesa efficace.

TL;DR — Cosa trovi in questa guida

• 25 tecniche di hardening WordPress ordinate per impatto, dalla configurazione del server al file system
• Snippet di codice pronti per wp-config.php, .htaccess e Nginx
• Configurazione di security headers, REST API, XML-RPC e author enumeration
• Checklist operativa per agenzie che gestiscono multi-sito WordPress
• Strategia difensiva a strati (defense-in-depth) testata su oltre 50 siti cliente

Cos’è l’Hardening WordPress e perché è diverso dalla sicurezza generica

L’hardening WordPress è il processo di rafforzamento della configurazione predefinita per ridurre la superficie di attacco. Diversamente da un plugin di sicurezza che reagisce alle minacce, l’hardening è preventivo: chiude le porte prima che qualcuno provi ad aprirle.

Nella nostra esperienza di gestione di oltre 50 siti WordPress con AgencyPilot, abbiamo identificato 25 tecniche di hardening che riducono il tasso di incidenti di sicurezza del 90%. Non è un numero teorico: è il risultato di aver applicato queste regole su ogni nuovo sito che entra nel nostro portfolio.

Il report Patchstack 2026 conferma che solo il 26% degli attacchi basati su vulnerabilità viene bloccato da strumenti di sicurezza a livello server. Questo significa che il 74% degli attacchi passa se il tuo hardening non è configurato correttamente.

1. Spostare wp-config.php fuori dalla root

Il file wp-config.php contiene le credenziali del database, le chiavi di sicurezza e la configurazione del sito. È il file più sensibile di tutta l’installazione. WordPress permette di spostarlo una directory sopra la root senza alcuna configurazione aggiuntiva.

# Sposta wp-config.php un livello sopra la root
mv /var/www/html/wp-config.php /var/www/wp-config.php

# WordPress lo trova automaticamente.
# Verifica che il file sia accessibile dal processo PHP:
chown www-data:www-data /var/www/wp-config.php
chmod 440 /var/www/wp-config.php

Se non puoi spostare il file (hosting condiviso), blocca l’accesso HTTP tramite .htaccess (vedi tecnica #8).

2. Permessi file e cartelle corretti

I permessi predefiniti di molte installazioni WordPress sono troppo permissivi. La regola d’oro:

# Imposta permessi corretti in massa
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 440 /var/www/html/wp-config.php
chmod 444 /var/www/html/.htaccess

3. Disabilitare l’editor di file nel backend

L’editor integrato di WordPress permette di modificare plugin e temi direttamente dal backend. Se un attaccante ottiene accesso amministrativo, può inserire backdoor in pochi secondi. Disabilitalo in wp-config.php:

// Disabilita editor file nel backend
define('DISALLOW_FILE_EDIT', true);

Questa singola riga è una delle misure di hardening WordPress più efficaci e sottovalutate.

4. Limitare le modifiche al file system

Se non hai bisogno di aggiornamenti automatici via backend (li gestisci tramite WP-CLI o AgencyPilot), disabilita anche la scrittura di file:

// Disabilita aggiornamenti e installazioni via backend
define('DISALLOW_FILE_MODS', true);

Attenzione: questo disabilita anche gli aggiornamenti dal pannello admin. È ideale per agenzie che gestiscono aggiornamenti centralizzati, come descritto nella nostra guida all’automazione WordPress.

5. Generare chiavi di sicurezza fresche

Le AUTH_KEY, SECURE_AUTH_KEY e NONCE_KEY in wp-config.php crittografano cookie e token. Se un sito è stato compromesso, queste chiavi devono essere rigenerate. Genera nuove chiavi dall’API ufficiale WordPress:

curl -s https://api.wordpress.org/secret-key/1.1/salt/

Nella nostra procedura di hardening, rigeneriamo le chiavi ogni 6 mesi come misura preventiva, non solo post-incident.

6. Cambiare il prefisso del database

Il prefisso predefinito wp_ rende gli attacchi SQL injection più prevedibili. Per una nuova installazione:

// In wp-config.php
$table_prefix = 'ap_7x9_';

Per un sito esistente, usa WP-CLI o uno script di migrazione. Non cambiarlo manualmente senza un backup completo prima.

7. Disabilitare XML-RPC

XML-RPC è un vettore di attacco comune per brute force e DDoS amplification. Il 99% dei siti moderni non lo usa. Disabilitalo tramite .htaccess:

# .htaccess - Blocca XML-RPC
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

Per Nginx:

# Nginx - Blocca XML-RPC
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

8. Proteggere wp-config.php via .htaccess

Se non puoi spostare wp-config.php (tecnica #1), blocca l’accesso HTTP diretto:

# .htaccess - Proteggi wp-config.php
<Files wp-config.php>
    Order Allow,Deny
    Deny from all
</Files>

9. Bloccare l’author enumeration

La tecnica di author enumeration permette a un attaccante di scoprire gli username validi aggiungendo ?author=1 all’URL. È il primo passo per un attacco brute force. Disabilitalo in .htaccess:

# .htaccess - Blocca author enumeration
RewriteCond %{QUERY_STRING} (author=\d+) [NC]
RewriteRule .* - [F]

Oppure in functions.php del tuo tema:

// functions.php - Rimuovi author enumeration
add_filter('redirect_canonical', function($redirect, $request) {
    if (preg_match('/\?author=([0-9]*)(\/*)/', $request)) {
        return false;
    }
    return $redirect;
}, 10, 2);

10. Disabilitare la directory browsing

Se il server non ha una pagina index, mostra il contenuto della cartella. Questo espone la struttura dei file e dei plugin. Disabilitalo:

# .htaccess - Disabilita directory browsing
Options -Indexes

11. Configurare i Security Headers

I security headers comunicano al browser come comportarsi con il contenuto del tuo sito. Sono una difesa contro XSS, clickjacking e MIME sniffing. Configurali in Nginx:

# Nginx - Security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:;" always;

Per Apache, aggiungili in .htaccess o nella configurazione del virtual host. Verifica il risultato con securityheaders.com.

12. Limitare la REST API WordPress

La REST API di WordPress espone dati pubblici che possono essere usati per reconnaissance. Gli endpoint /wp-json/wp/v2/users rivelano gli username amministratori. Nella nostra guida alla REST API approfondiamo questo aspetto.

Per bloccare l’endpoint users senza rompere altre funzionalità:

// functions.php - Rimuovi endpoint users dalla REST API
add_filter('rest_endpoints', function($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    if (isset($endpoints['/wp/v2/users/(?P[\d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P[\d]+)']);
    }
    return $endpoints;
});

13. Proteggere wp-login.php con HTTP Basic Auth

Aggiungi un secondo livello di autenticazione davanti a wp-login.php:

# .htaccess - Proteggi wp-login.php
<Files wp-login.php>
    AuthName "Admin Area"
    AuthType Basic
    AuthUserFile /var/www/.htpasswd
    Require valid-user
</Files>

# Crea il file .htpasswd
htpasswd -c /var/www/.htpasswd admin_user

Per un’alternativa più moderna, consulta la nostra guida alla sicurezza WordPress per agenzie.

14. Limitare i tentativi di login (Rate Limiting)

Il brute force sui login è automatizzato e costante. Implementa un rate limit a livello server:

# Nginx - Rate limit su wp-login.php
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    # ... resto della configurazione
}

15. Disabilitare il JSON REST API per utenti non autenticati

Oltre a bloccare l’endpoint users (tecnica #12), puoi disabilitare completamente la REST API per visitatori anonimi se il tuo sito non la usa:

// functions.php - Disabilita REST API per non autenticati
add_filter('rest_authentication_errors', function($result) {
    if (!is_user_logged_in()) {
        return new WP_Error('rest_disabled', __('REST API disabled'), array('status' => 403));
    }
    return $result;
});

16. Nascondere la versione di WordPress

La versione di WordPress visibile nel codice sorgente aiuta gli attaccanti a identificare vulnerabilità note. Rimuovila:

// functions.php - Rimuovi versione WordPress
remove_action('wp_head', 'wp_generator');
add_filter('the_generator', '__return_empty_string');

// Rimuovi versione dai feed RSS
add_filter('style_loader_src', function($src) {
    if (strpos($src, 'ver=')) {
        $src = remove_query_arg('ver', $src);
    }
    return $src;
});

17. Disabilitare PHP error display in produzione

Gli errori PHP visualizzati rivelano percorsi del server e informazioni sensibili. In wp-config.php:

// wp-config.php - Disabilita error display
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
define('WP_DEBUG_LOG', true); // Logga su wp-content/debug.log

18. Bloccare l’accesso a wp-content/uploads

La cartella uploads non dovrebbe mai eseguire file PHP. Se un attaccante carica uno script, questo hardening lo neutralizza:

# .htaccess in wp-content/uploads/
<Files *.php>
    Deny from all
</Files>

Per Nginx:

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

19. Disabilitare i file PHP in /wp-includes/

I file in wp-includes non dovrebbero mai essere accessibili direttamente via HTTP:

# .htaccess - Blocca PHP in wp-includes
<IfModule mod_rewrite.c>
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
</IfModule>

20. Configurare HTTPS forzato e HSTS

Forza HTTPS a livello di server e attiva HSTS per prevenire attacchi downgrade:

# Nginx - Redirect HTTP a HTTPS + HSTS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    # ... resto della configurazione SSL
}

21. Implementare 2FA per tutti gli amministratori

Il two-factor authentication è l’ultima linea di difesa se le credenziali vengono rubate. Per agenzie che gestiscono multi-sito, implementa 2FA a livello server o tramite plugin come Wordfence o Solid Security. Tutti gli account amministratore devono avere 2FA attivo, senza eccezioni.

22. Limitare l’accesso a /wp-admin/ per IP

Se la tua agenzia usa IP fissi, limita l’accesso al pannello admin:

# .htaccess - Limita /wp-admin/ per IP
<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from 192.168.1.0/24
    Allow from 203.0.113.45
</Files>

Per agenzie con IP dinamici, usa una VPN o un servizio come Cloudflare Access.

23. Disabilitare i pingback e trackback

I pingback sono usati per DDoS amplification e scanning. Disabilitali:

// functions.php - Disabilita pingback
add_filter('xmlrpc_methods', function($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    return $methods;
});

// Disabilita self-ping
add_action('pre_ping', function(&$links) {
    $home = get_option('home');
    foreach ($links as $l => $link) {
        if (0 === strpos($link, $home)) {
            unset($links[$l]);
        }
    }
});

24. Monitorare i cambiamenti ai file core

Un file core modificato è il segnale di un’intrusione. Usa WP-CLI per verificare l’integrità dei file:

# Verifica integrità file core
wp core verify-checksums

# Per i plugin piu popolari
wp plugin verify-checksums --all

Nella nostra gestione con AgencyPilot, automatizziamo questo check settimanalmente su tutti i siti. Se un file non corrisponde agli hash ufficiali, riceviamo un alert immediato.

25. Implementare un WAF a livello server

Un Web Application Firewall filtra il traffico malevolo prima che raggiunga WordPress. Le opzioni migliori per agenzie:

• Cloudflare WAF: regole custom, protezione DDoS, CDN integrata
• ModSecurity con le regole OWASP CRS: open source, si installa sul server
• Sucuri Firewall: proxy inverso con WAF e cleanup incluso

Il report Patchstack 2026 indica che un WAF ben configurato blocca fino al 74% degli attacchi basati su vulnerabilità. Non è un sostituto dell’hardening, ma un complemento essenziale.

Checklist Hardening WordPress per Agenzie Multi-Sito

Per agenzie che gestiscono 10+ siti, l’hardening manuale non è scalabile. Ecco la nostra checklist automatizzata con WP-CLI:

Con AgencyPilot, applichiamo tutte le 25 tecniche in meno di 15 minuti per sito tramite script centralizzati. Il monitoraggio continuo rileva modifiche ai file core, tentativi di login sospetti e cambiamenti di configurazione.

FAQ — Hardening WordPress

L’hardening WordPress rallenta il sito?

No. La maggior parte delle tecniche di hardening (permessi file, security headers, blocco XML-RPC) non ha impatto sulle performance. Il rate limiting su wp-login.php influisce solo sui tentativi di accesso, non sul traffico normale. Un WAF può aggiungere 10-50ms di latenza, ma il beneficio di sicurezza è superiore al costo.

Quali tecniche di hardening sono piu importanti?

Le tre piu critiche in ordine di impatto: (1) disabilitare l’editor di file nel backend, (2) configurare permessi file corretti, (3) bloccare l’author enumeration. Queste tre da sole prevengono il 60% degli attacchi piu comuni.

Devo fare hardening anche se uso un plugin di sicurezza?

Si. I plugin di sicurezza come Wordfence o Solid Security sono complementari all’hardening, non sostitutivi. L’hardening riduce la superficie di attacco, il plugin rileva e risponde alle minacce. Il report Patchstack 2026 mostra che il 74% degli attacchi basati su vulnerabilità non viene bloccato dai soli strumenti server.

Quanto spesso devo verificare l’hardening?

Verifica mensile per siti con traffico medio, settimanale per e-commerce o siti PA. Rigenera le chiavi di sicurezza ogni 6 mesi. Verifica l’integrità dei file core con wp core verify-checksums dopo ogni aggiornamento.

L’hardening è compatibile con WordPress multisite?

Si, ma alcune tecniche richiedono adattamenti. Il rate limiting su wp-login.php deve considerare il login centralizzato. I security headers si configurano a livello server, non di sito. I permessi file sono identici. Per il multisite, automatizza l’hardening tramite script WP-CLI.

Conclusione

L’hardening WordPress non è un evento una-tantum ma un processo continuo. Le 25 tecniche descritte in questa guida formano un sistema di defense-in-depth che riduce drasticamente la probabilità di compromissione. Per agenzie che gestiscono multi-sito, l’automazione è l’unico modo per applicare hardening in modo consistente e scalabile.

Nella nostra esperienza con AgencyPilot, un sito correttamente hardenato richiede il 90% di interventi di sicurezza in meno rispetto a un’installazione predefinita. Considerando che il costo medio di un incidente di sicurezza WordPress è di 3-8 ore di lavoro, l’hardening preventivo ha un ROI immediato.

Se gestisci piu siti WordPress e vuoi applicare queste 25 tecniche in modo automatizzato, scopri come AgencyPilot centralizza hardening, monitoraggio e gestione per agenzie.