L’hardening è l’insieme delle configurazioni che riducono la superficie d’attacco di un sito: proteggere i file sensibili, impostare i permessi giusti, disattivare ciò che non serve. In questo articolo vediamo le misure più efficaci, con esempi di codice, e con un’avvertenza importante da leggere prima di iniziare.
Cosa significa “hardening” e perché conta
Il termine hardening (letteralmente “irrobustimento”) indica tutte quelle configurazioni che rendono un’installazione di WordPress più difficile da attaccare. L’idea di fondo è semplice: ridurre la superficie d’attacco, cioè il numero di punti attraverso cui qualcuno potrebbe provare a entrare o a fare danni.
La maggior parte delle violazioni non nasce da falle misteriose, ma da impostazioni trascurate, permessi sbagliati e funzioni attive che nessuno usa. L’hardening interviene esattamente qui: chiude le porte che non servono e mette al riparo i file più delicati. È il livello più tecnico di quella sicurezza intesa come processo e non solo come plugin di cui abbiamo già parlato.
Prima di toccare qualcosa: un’avvertenza
Le misure descritte in questo articolo agiscono su file di sistema come wp-config.php e .htaccess, sui permessi del filesystem e sulla configurazione del server. Sono interventi efficaci, ma anche delicati: un errore di battitura in questi file può rendere il sito irraggiungibile.
Per questo, tre regole valgono prima di ogni modifica. Primo: fai un backup completo e assicurati di saperlo ripristinare. Secondo: prova le modifiche in un ambiente di staging, non direttamente sul sito online. Terzo, e più importante: se non hai dimestichezza con questi file, non sperimentare sul sito di produzione: meglio rivolgersi a uno sviluppatore o al supporto dell’hosting. Molte di queste protezioni, come vedremo, possono essere applicate anche in modo più sicuro tramite un plugin o l’hosting stesso, senza mettere le mani nel codice.
Detto questo, vediamo le misure una per una.
Proteggere il file wp-config.php
Il file wp-config.php è il più sensibile dell’intera installazione: contiene le credenziali del database, le chiavi di sicurezza e la configurazione di base. Proteggerlo è la priorità numero uno.
Una prima misura è impedirne l’accesso diretto dal browser. Su server Apache, lo si fa aggiungendo questa regola al file .htaccess:
<Files wp-config.php>
Require all denied
</Files>
È inoltre buona norma rigenerare periodicamente le chiavi e i “sali” di sicurezza, che WordPress usa per proteggere sessioni e cookie. Si possono generare valori nuovi dal servizio ufficiale https://api.wordpress.org/secret-key/1.1/salt/ e incollarli nella sezione dedicata di wp-config.php. Cambiarli forza la disconnessione di tutte le sessioni attive, il che è esattamente ciò che si vuole in caso di sospetta compromissione.
Infine, è utile forzare l’uso di HTTPS nell’area di amministrazione, aggiungendo in wp-config.php, prima della riga che richiede wp-settings.php:
define( 'FORCE_SSL_ADMIN', true );
Disattivare l’editor di file dal pannello
WordPress include un editor che permette di modificare i file di temi e plugin direttamente dalla bacheca. È comodo, ma è anche un regalo per un eventuale attaccante: chi ottenesse l’accesso da amministratore potrebbe iniettare codice dannoso senza nemmeno toccare il server.
Su un sito di produzione, questa funzione andrebbe quasi sempre disattivata. Basta aggiungere a wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );
Esiste anche una misura più drastica, DISALLOW_FILE_MODS, che blocca del tutto l’installazione e l’aggiornamento di temi e plugin dalla bacheca. Va però usata con cautela: impedisce anche gli aggiornamenti, che, come abbiamo visto parlando di come aggiornare in sicurezza, sono fondamentali. Ha senso solo in scenari gestiti, dove gli aggiornamenti vengono applicati con un altro flusso controllato.
Impostare i permessi corretti di file e cartelle
I permessi del filesystem stabiliscono chi può leggere, scrivere ed eseguire ogni file. Permessi troppo aperti sono un rischio classico. La configurazione consigliata per WordPress è:
- Cartelle:
755 - File:
644 wp-config.php:600(o640, a seconda della configurazione dell’hosting)
Da riga di comando, tramite accesso SSH alla cartella principale di WordPress, si possono applicare così (in alternativa, un client FTP permette di modificare i permessi dei singoli file dalla sua interfaccia):
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php
Su molti hosting condivisi i permessi sono già impostati correttamente; conviene verificarlo, ma evitare scorciatoie pericolose come il permesso 777, che rende un file scrivibile da chiunque e va evitato sempre.
Disattivare XML-RPC se non serve
xmlrpc.php è una vecchia API di WordPress che oggi la maggior parte dei siti non utilizza. Purtroppo viene spesso sfruttata per attacchi a forza bruta e per amplificare attacchi DDoS. Se non usi l’app mobile di WordPress né servizi che lo richiedono espressamente, conviene disattivarla.
Su Apache, si può bloccare l’accesso al file con una regola in .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>
In alternativa, quasi tutti i plugin di sicurezza offrono un’opzione per disattivare XML-RPC con un clic, che è la via più semplice e meno soggetta a errori.
Aggiungere gli header di sicurezza
Gli header di sicurezza sono istruzioni che il server invia al browser per ridurre alcune classi di attacchi. WordPress non li imposta da solo, quindi vanno aggiunti a livello di server. Su Apache, con il modulo mod_headers attivo, si possono aggiungere in .htaccess:
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>
In breve: X-Content-Type-Options impedisce al browser di “indovinare” il tipo dei file; X-Frame-Options protegge dal clickjacking impedendo che il sito venga incorniciato in altri siti; Referrer-Policy limita le informazioni inviate quando si segue un link; Strict-Transport-Security (HSTS) impone l’uso di HTTPS. Attenzione a HSTS: vale la pena attivarlo solo quando si è certi che tutto il sito funzioni correttamente in HTTPS. Un header più potente ma anche più complesso, la Content-Security-Policy, va configurato con attenzione caso per caso. Chi usa server Nginx applica gli stessi header con una sintassi diversa, nella configurazione del server.
Ridurre la superficie d’attacco
Oltre alle singole configurazioni, l’hardening è anche una questione di igiene generale. Alcune buone pratiche che riducono i punti di ingresso:
- Rimuovere temi e plugin inutilizzati, non solo disattivarli: anche un’estensione inattiva può contenere vulnerabilità sfruttabili.
- Gestire con criterio i ruoli utente, applicando il principio del privilegio minimo e limitando gli account amministratori.
- Evitare l’enumerazione degli utenti, ovvero la possibilità di scoprire i nomi utente tramite certi URL o la REST API: molti plugin di sicurezza offrono un’opzione apposita.
- Non esporre informazioni superflue, come la versione di WordPress in uso, che può aiutare un attaccante a individuare vulnerabilità specifiche.
Sono interventi semplici, ma che insieme restringono parecchio lo spazio di manovra di un eventuale attacco.
Cosa lasciare a plugin e hosting
Vale la pena ribadirlo: molte delle misure viste qui non richiedono di mettere le mani nei file. I plugin di sicurezza permettono di disattivare XML-RPC, aggiungere header, bloccare l’enumerazione degli utenti e applicare diversi irrobustimenti con interfacce sicure e reversibili. Allo stesso modo, un buon hosting gestisce spesso permessi, isolamento e regole del server al posto tuo.
La scelta tra configurazione manuale e plugin non è una questione di “più bravo o meno bravo”, ma di contesto: chi sviluppa e gestisce molti siti spesso preferisce il controllo diretto del codice; chi gestisce il proprio sito trova nei plugin un modo più sicuro di ottenere lo stesso risultato senza rischiare di rompere nulla.
Errori da evitare
L’errore più frequente, in tema di hardening, è proprio sperimentare sul sito di produzione senza backup né ambiente di prova: una singola riga sbagliata in .htaccess o wp-config.php può bloccare tutto. Altri errori comuni sono impostare permessi troppo permissivi (il famigerato 777), attivare HSTS prima di aver messo in sicurezza l’HTTPS, oppure usare DISALLOW_FILE_MODS dimenticando che blocca anche gli aggiornamenti.
Infine, l’hardening non è un’attività “una tantum”: va rivisto quando cambiano l’hosting, la struttura del sito o le esigenze. Si integra naturalmente con la checklist per il primo sito WordPress e con le altre buone pratiche della serie.
Prossimi passi
Il consiglio pratico è procedere per gradi e senza fretta: partire dalle misure a maggior impatto e minor rischio (proteggere wp-config.php, disattivare l’editor di file, verificare i permessi) e solo dopo affrontare header e configurazioni più avanzate, sempre con un backup pronto e, se possibile, su un ambiente di staging.
E se un passaggio non è chiaro, la scelta più saggia non è tirare a indovinare, ma chiedere a uno sviluppatore o affidarsi a un plugin che faccia il lavoro in modo controllato. L’hardening è un potente alleato della sicurezza, a patto di applicarlo con metodo e con le giuste precauzioni.
