Salta al contenuto principale
Sistemi Attivi
WP Planet — WordPress Cloud & Managed Services
Torna al MagazineSicurezza

Hardening WordPress: 12 controlli per blindare un sito prima che venga attaccato

14 Ott 2026 — 12:45 9 min di lettura
Hardening WordPress: 12 controlli per blindare un sito prima che venga attaccato

L'hardening è il lavoro preventivo che riduce la superficie d'attacco. 12 controlli concreti: limitare login, bloccare XML-RPC, nascondere versione, proteggere wp-admin e verificare i file con checksum.

L'hardening è l'insieme delle misure preventive che riducono la superficie d'attacco di un sito WordPress prima che qualcuno tenti di violarlo. A differenza della bonifica malware — che interviene dopo — l'hardening è il lavoro che si fa prima, quando tutto funziona, per evitare che smetta di funzionare.

Un WordPress di base ha diverse porte d'ingresso che gli attaccanti conoscono perfettamente: wp-login.php per il brute force, xmlrpc.php per il multicall, wp-content/uploads per l'iniezione di file, la versione visibile di core e plugin per scegliere l'exploit giusto. Chiudere o limitare queste porte è il cuore dell'hardening.

1. Limitare i tentativi di login

Senza un limite, un attaccante può tentare migliaia di password al minuto. Un plugin come Limit Login Attempts Reloaded o un filtro custom blocca gli IP dopo N tentativi falliti.

wp-config.php
// Limite custom di login nel file functions.php
add_action( 'wp_login_failed', function( $username ) {
    $ip = $_SERVER['REMOTE_ADDR'];
    $attempts = (int) get_transient( 'login_fails_' . $ip ) + 1;
    set_transient( 'login_fails_' . $ip, $attempts, 15 * MINUTE_IN_SECONDS );
    if ( $attempts > 5 ) {
        set_transient( 'login_blocked_' . $ip, true, 30 * MINUTE_IN_SECONDS );
    }
});
add_filter( 'authenticate', function( $user, $username ) {
    $ip = $_SERVER['REMOTE_ADDR'];
    if ( get_transient( 'login_blocked_' . $ip ) ) {
        return new WP_Error( 'too_many_attempts', 'Troppi tentativi. Riprova tra 30 minuti.' );
    }
    return $user;
}, 30, 2 );
Nota: Questo è un esempio minimale. In produzione usa un plugin dedicato o un WAF con rate limiting, che blocca gli IP prima che raggiungano WordPress.

2. Bloccare XML-RPC

XML-RPC espone il metodo system.multicall che permette centinaia di tentativi di login in una sola richiesta. Se non usi app mobili o Jetpack, disabilita l'accesso al file dal web server:

.htaccess
# Blocca xmlrpc.php in .htaccess
<Files xmlrpc.php>
    Require all denied
</Files>
Nota: Verifica che nessuna integrazione (Jetpack, app mobili, strumenti di pubblicazione remota) si appoggi a XML-RPC prima di bloccarlo.

3. Nascondere la versione di WordPress

La versione visibile nel meta generator aiuta gli attaccanti a scegliere l'exploit giusto. Rimuovila con un filtro:

wp-config.php
// Rimuovi il meta generator di WordPress
remove_action( 'wp_head', 'wp_generator' );

// Rimuovi anche dalle manifest e dai feed
add_filter( 'the_generator', '__return_empty_string' );

// Nascondi versione nei feed RSS
add_filter( 'style_loader_src', function( $src ) {
    return remove_query_arg( 'ver', $src );
}, 10 );
Nota: Questo non rende il sito sicuro, ma rimuove un'informazione gratuita per gli attaccanti. La sicurezza dipende dagli aggiornamenti, non dal nascondere la versione.

4. Proteggere wp-admin con restrizioni IP

Se gli amministratori accedono da IP fissi (ufficio, VPN), limita l'accesso a wp-admin solo a quegli indirizzi:

.htaccess
# Limita wp-login.php e wp-admin a IP autorizzati
<Files wp-login.php>
    Require ip 192.168.1.0/24
    Require ip 203.0.113.50
</Files>

# Proteggi l'intera area admin
<Directory /var/www/wp-admin>
    Require ip 192.168.1.0/24
</Directory>
Nota: Se il tuo IP è dinamico o usi cloud hosting, usa un WAF con autenticazione a due fattori invece del blocco IP.

5. Verificare i file con i checksum ufficiali

WordPress può verificare se i file core sono stati modificati o compromessi confrontandoli con i checksum ufficiali. Esegui questo controllo periodicamente:

Terminale
# WP-CLI: verifica integrità dei file core
wp core verify-checksums

# Output atteso:
# Success: WordPress installation verifies against checksums.
# Se c'è un mismatch, un file core è stato modificato o compromesso.
Nota: Un mismatch nei checksum dei file core è un segnale di possibile compromissione. Confronta con un'installazione pulita o ripristina dal backup.

6–12. Gli altri controlli fondamentali

Gli altri controlli essenziali sono: disabilitare l'editor di plugin e temi dal pannello admin, forzare HTTPS su tutto il sito, proteggere wp-config.php con permessi restrittivi (640 o 600), disabilitare la registrazione utenti se non necessaria, usare password complesse e autenticazione a due fattori per gli amministratori, monitorare i file con scanner malware periodici, e limitare le dimensioni di upload. Disabilitare l'editor di file è una riga sola:

wp-config.php
// Disabilita l'editor di plugin e temi dal pannello admin
define( 'DISALLOW_FILE_EDIT', true );

// Disabilita anche l'installazione di plugin/temi dal pannello
// (utile per ambienti gestiti da team tecnico)
define( 'DISALLOW_FILE_MODS', true );
Nota: DISALLOW_FILE_EDIT impedisce che un utente admin compromesso modifichi il codice dei plugin dal browser. È uno dei controlli più importanti e si fa con una riga.

L'hardening non è un lavoro una tantum: è un'abitudine. Le minacce evolvono, i plugin si aggiornano, le configurazioni si driftano. Un audit di sicurezza periodico verifica che i 12 controlli siano tutti attivi e che non ci siano regressioni. In WP Planet, l'hardening è incluso in ogni piano di sicurezza come parte del setup iniziale.

Audit di sicurezza

Verifica la sicurezza del tuo WordPress prima che diventi un'emergenza.

Un audit di sicurezza individua le falle, i plugin vulnerabili e le configurazioni deboli prima che qualcuno le sfrutti.

Audit di sicurezza
Condividi