🔒 Header keamanan HTTP untuk WordPress: panduan pengaturan lengkap

Il tuo sito WordPress è attivo, il plugin di sicurezza è installato, ma un controllo su securityheaders.com ti restituisce una F. Ti suona familiare?

Gli header HTTP di sicurezza sono uno strato di protezione invisibile che viene trascurato anche dopo aver configurato un firewall e l'autenticazione a due fattori. Non richiedono rinnovi di licenza, non caricano il server e bloccano intere classi di attacchi: dal clickjacking al furto di sessione. E si aggiungono in 10 minuti.

Di seguito, passo dopo passo: quali header ti servono davvero, come configurarli tramite.htaccess, functions.php o un plugin, e come verificare che la protezione sia attiva, non solo dichiarata.

💡 Panoramica rapida:

• Verifica gli header attuali del tuo sito con securityheaders.com o Mozilla Observatory per vedere la situazione reale
• Attiva un set base di 4-5 header: X-Content-Type-Options, X-Frame-Options, HSTS, Referrer-Policy, Permissions-Policy
• Scegli il metodo: un paio di righe in.htaccess (Apache/LiteSpeed), uno snippet in functions.php, o il plugin Headers Security Advanced & HSTS WP
• Lascia CSP per dopo: è delicato da configurare e rompe Gutenberg se fatto senza test
• Dopo l'implementazione, ricontrolla: un punteggio A+ è raggiungibile in 10 minuti

Cosa sono gli header HTTP di sicurezza

Quando un browser richiede una pagina, il server web risponde con qualcosa di più del semplice codice HTML. Ogni risposta HTTP contiene campi di servizio, gli header. Alcuni gestiscono la cache e il tipo di contenuto, altri la sicurezza.

Il browser legge gli header di sicurezza prima ancora di iniziare a renderizzare la pagina. Se il server dice «vieto l'incorporamento di questo sito in frame», il browser non lo farà, anche se il codice della pagina contiene un <iframe>. Se il server dice «usa solo HTTPS per un anno», il browser lo ricorda e non andrà alla versione HTTP, anche se l'utente la digita manualmente.

Nessun JavaScript, nessun plugin, nessun firewall può influire su questo. Siamo a livello di protocollo. È proprio questo il motivo per cui gli header sono una linea di difesa separata e indipendente.

Perché un sito WordPress ne ha bisogno

I plugin di sicurezza come Wordfence o Solid Security chiudono le vulnerabilità a livello applicativo: forza bruta, injection, caricamenti malevoli. Gli header HTTP lavorano un livello più in alto: proteggono il canale di comunicazione stesso tra il server e il visitatore.

Ecco cosa bloccano gli header configurati correttamente:

• Clickjacking. Un aggressore incorpora il tuo sito in un frame trasparente sopra il proprio e intercetta i clic dell'utente. Bloccato dall'header X-Frame-Options o dalla direttiva frame-ancestors nel CSP.

• MIME sniffing. Il browser prova a «indovinare» il tipo di file e può eseguire un'immagine caricata come JavaScript. Bloccato da X-Content-Type-Options: nosniff.

• Furto di sessione. Un aggressore su una rete Wi-Fi aperta altera la risposta del server e ruba i cookie di login. HSTS impedisce al browser di accedere alla versione HTTP del sito.

• Perdita di referrer. Quando si segue un link esterno, il sito di destinazione vede da quale pagina proviene l'utente, incluso l'URL con i parametri. Referrer-Policy limita questa informazione.

• Accesso non autorizzato ai dispositivi. Una pagina web richiede microfono, fotocamera o geolocalizzazione all'insaputa dell'utente. Permissions-Policy blocca queste richieste a livello di browser.

CSP aggiunge un ulteriore strato: definisci esplicitamente quali domini possono caricare script, stili e font. Anche se codice malevolo finisse nel database, il browser non lo eseguirebbe perché l'origine non è nella lista consentita. Ma CSP richiede attenzione: un piccolo errore e l'editor Gutenberg smette di funzionare.

Header HTTP di sicurezza principali: cosa includono e perché

Di seguito gli header che vale la pena configurare su qualsiasi sito WordPress. Per ciascuno specifichiamo: da quale attacco protegge, il valore consigliato e dove potrebbero verificarsi problemi.

X-Content-Type-Options

Il più semplice e sicuro da configurare. L'unico valore valido è nosniff. Il browser smette di "indovinare" il tipo MIME di un file in base al suo contenuto e si fida solo del tipo inviato dal server nell'header Content-Type.

Senza questo header, il browser potrebbe interpretare un'immagine caricata da un utente come uno script ed eseguirla, uno scenario classico di attacco tramite caricamento file.

Valore consigliato: nosniff

Rischi di rottura: minimi. I problemi sono possibili solo se il server serve file con un Content-Type errato, ma è un problema a sé che vale la pena correggere anziché mascherare.

X-Frame-Options

Controlla se il tuo sito può essere incorporato in un <frame>, <iframe> o <object> su un altro sito.

Due valori principali:

• DENY, divieto totale di incorporamento. Protezione massima.
• SAMEORIGIN, incorporamento consentito solo dallo stesso dominio. Necessario se usi tu stesso i frame per le tue pagine (ad esempio, anteprima nel pannello di amministrazione).

Per la maggior parte dei siti WordPress, SAMEORIGIN funziona. Se sai per certo che non vengono usati frame, imposta DENY.

Valore consigliato: SAMEORIGIN

Rischi di rottura: alcuni plugin usano iframe per le anteprime. Se qualcosa smette di essere visualizzato nel pannello di amministrazione dopo aver attivato DENY, passa a SAMEORIGIN.

Strict-Transport-Security (HSTS)

Dice al browser: "per i prossimi N secondi, accedi a questo dominio solo tramite HTTPS". Protegge dagli attacchi di downgrade e dal furto di cookie su reti aperte.

Il parametro chiave è max-age. Si consiglia di iniziare con un valore basso (un giorno o una settimana) e, dopo verifica, aumentarlo a un anno.

Il parametro opzionale includeSubDomains estende la regola a tutti i sottodomini, importante se ne hai diversi e usi una CDN.

Il parametro preload aggiunge il sito alla lista HSTS globale dei browser: Chrome, Firefox e Safari accederanno al tuo dominio solo tramite HTTPS già prima della prima richiesta. Invia una richiesta tramite hstspreload.org.

Valore consigliato: max-age=31536000; includeSubDomains

Rischi di rottura: se attivi HSTS e il certificato SSL scade, gli utenti non potranno più accedere al sito. Tieni d'occhio il rinnovo automatico del certificato.

Referrer-Policy

Gestisce quali informazioni sulla pagina di origine il browser invia quando si segue un link verso un altro sito.

Valori principali, dal più restrittivo al più permissivo:

• no-referrer, non viene inviato nulla.
• strict-origin-when-cross-origin, verso un dominio diverso viene inviato solo il dominio (nessun percorso o parametro); verso il proprio, l'URL completo. L'equilibrio ottimale tra privacy e analytics.
• strict-origin, sempre e solo il dominio, nessun percorso.

Se non vuoi che i siti di destinazione sappiano da dove proviene l'utente, imposta no-referrer. Ma tieni presente: perderai il traffico di referral nella tua stessa analytics.

Valore consigliato: strict-origin-when-cross-origin

Rischi di rottura: minimi. Alcuni servizi di terze parti potrebbero richiedere un referrer per funzionare (ad esempio, gateway di pagamento con verifica dell'origine). Puoi tracciare questi casi tramite la console del browser.

Permissions-Policy

Precedentemente chiamata Feature-Policy. Limita l'accesso della pagina web alle API "hardware" del browser: microfono, fotocamera, geolocalizzazione, USB, API di pagamento e così via.

Formato: название-фичи=(разрешённый-источник). Ad esempio:

1
Permissions-Policy: camera=(), microphone=(), geolocation=(self)

Questo esempio blocca completamente l'accesso a fotocamera e microfono per tutte le origini e consente la geolocalizzazione solo per il sito stesso (self).

Elenco completo delle funzionalità su MDN. Per un sito WordPress senza videochiamate e funzionalità PWA, è sufficiente bloccare fotocamera, microfono e geolocalizzazione; il resto è opzionale.

Valore consigliato: dipende dalle funzionalità del sito. Minimo: camera=(), microphone=(), geolocation=(self).

Rischi di rottura: se il sito ha funzionalità di videochiamata, PWA o WebUSB, verifica quali funzionalità richiede e non bloccarle.

Content-Security-Policy (CSP)

L'header più potente e più pericoloso da configurare. Definisce una lista di origini consentite per script, stili, font, immagini, frame e altre risorse.

Esempio di policy minima per WordPress:

1
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;
2

Perché unsafe-inline e unsafe-eval: WordPress, Gutenberg e decine di plugin generano script inline e usano eval(). Senza queste direttive, il pannello di amministrazione semplicemente non funziona. Questo è il prezzo della compatibilità.

Raccomandazione: non attivare CSP per primo. Configura prima gli altri 5 header. Implementa CSP solo se hai le risorse per test e monitoraggio; inizia con la modalità Content-Security-Policy-Report-Only e raccogli i log delle violazioni per un paio di settimane prima di passare alla modalità enforce.

Rischi di rottura: elevati. Un errore nel CSP può rompere completamente il frontend e il pannello di amministrazione. Testa sempre su un ambiente di staging o tramite Report-Only.

Come verificare gli header attuali del tuo sito

Prima di configurare, un audit. Tre strumenti, dal semplice al dettagliato:

• securityheaders.com, inserisci l'URL e ottieni un punteggio da A+ a F con un dettaglio per ogni header. Gratuito, senza registrazione.

• Mozilla Observatory, un audit più dettagliato: valuta non solo gli header ma anche le impostazioni TLS, gli attributi dei cookie, CORS e altri aspetti. Anch'esso gratuito.

• Chrome DevTools, apri la scheda Network, seleziona una qualsiasi richiesta al tuo sito e guarda la sezione Response Headers. Un modo rapido per verificare se le modifiche hanno "attecchito" dopo aver modificato.htaccess.

Controlla subito il tuo sito. Se il punteggio è inferiore a B, non hai nemmeno gli header di base e un terzo delle voci seguenti le configurerai in 5 minuti.

Modi per configurare gli header HTTP in WordPress

Tre percorsi, dal manuale all'automatico. Scegli in base alla tua situazione.

Metodo 1: via.htaccess (Apache/LiteSpeed)

Il metodo più rapido per siti su Apache o LiteSpeed. Aggiungi al file .htaccess nella root del sito (prima di # BEGIN WordPress):

1
<IfModule mod_headers.c>
2
    Header set X-Content-Type-Options "nosniff"
3
    Header set X-Frame-Options "SAMEORIGIN"
4
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
5
    Header set Referrer-Policy "strict-origin-when-cross-origin"
6
    Header set Permissions-Policy "camera=(), microphone=(), geolocation=(self)"
7
</IfModule>

Il wrapper <IfModule mod_headers.c> assicura che il sito non vada in crash con un errore 500 se il modulo mod_headers non è abilitato. Se sai con certezza che è attivo, puoi ometterlo.

Dopo aver salvato, esegui nel terminale (se hai WP-CLI) o semplicemente apri il sito e verifica gli header tramite securityheaders.com. Le modifiche in .htaccess si applicano all'istante; non serve riavviare il server.

Metodo 2: via functions.php (Nginx / universale)

Funziona indipendentemente dal web server, adatto sia a Nginx che ad Apache. Aggiungi al functions.php del tuo child theme o tramite il plugin Code Snippets:

1
function sdstudio_add_security_headers() {
2
    header( 'X-Content-Type-Options: nosniff' );
3
    header( 'X-Frame-Options: SAMEORIGIN' );
4
    header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains' );
5
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
6
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=(self)' );
7
}
8
add_action( 'send_headers', 'sdstudio_add_security_headers' );

L'hook send_headers si attiva prima che WordPress inizi a inviare contenuti, quindi gli header partono nella primissima risposta del server.

Per Nginx, questo metodo è preferibile rispetto a mettere mano alla configurazione del server (specialmente su hosting condiviso, dove l'accesso a nginx.conf spesso non è disponibile). Lo svantaggio: gli header funzionano solo per le richieste PHP che passano attraverso WordPress. I file statici (immagini, CSS, JS) sono serviti direttamente da Nginx e non riceveranno gli header. Per questi serve una configurazione a livello server.

Metodo 3: via il plugin headers security advanced & hsts wp

Se non vuoi toccare codice, usa un plugin dedicato. Headers Security Advanced & HSTS WP raccoglie tutti gli header di sicurezza in un'unica interfaccia e li abilita con un solo pulsante.

Il plugin imposta valori predefiniti per tutti gli header chiave subito dopo l'attivazione: X-Content-Type-Options, X-Frame-Options, HSTS, CSP, Referrer-Policy, Permissions-Policy e diversi altri aggiuntivi (CORP, COOP, COEP). Ogni header può essere disabilitato o personalizzato in base alle tue esigenze.

Il vantaggio di questo approccio: il plugin non dipende dal web server e funziona in modo identico su Apache, Nginx, LiteSpeed e IIS. Alla disattivazione, riporta la configurazione del sito allo stato originale.

Alternativa: Redirection

Il plugin Redirection è noto come gestore di redirect, ma può anche aggiungere header HTTP. Dopo l'installazione e la configurazione di base, vai alla sezione Site → Headers; l'interfaccia ti permette di specificare qualsiasi coppia "header: valore".

Questa opzione è utile se hai già Redirection installato per la gestione dei link e non vuoi aggiungere un altro plugin. Ma un plugin dedicato agli header offre più controllo e valori preimpostati.

Nel video, una dimostrazione visiva della configurazione degli header tramite il plugin Headers Security Advanced: dall'installazione alla verifica del risultato su securityheaders.com.

⁉️🤔 Domande frequenti

Cosa fare se il sito si rompe dopo aver abilitato gli header?

Per prima cosa, controlla l'header Content-Security-Policy: è la causa della stragrande maggioranza dei blocchi. Disabilita il CSP (o passalo in modalità Report-Only) e ricontrolla il sito. Errore 500 dopo aver modificato.htaccess: verifica la sintassi per uno spazio di troppo, virgolette non chiuse o il modulo mod_headers mancante. Via FTP, rinomina.htaccess, il sito tornerà in vita e potrai trovare l'errore con calma.

In 9 casi su 10, il problema è specificamente il CSP, non gli altri header. X-Content-Type-Options, X-Frame-Options, HSTS e Referrer-Policy non possono fisicamente rompere il sito; non influenzano il rendering o la logica PHP. Inizia sempre da quelli.

È obbligatorio un plugin o si può fare via codice?

Si può e si dovrebbe fare via codice se sai come modificare functions.php o.htaccess. Impostare gli header direttamente tramite la configurazione del server funziona più velocemente di un plugin, senza un livello PHP in mezzo. Ma un plugin è più comodo per chi non vuole toccare codice e fornisce un'interfaccia visiva con preset per ogni header.

Sui nostri siti di test usiamo entrambi gli approcci: in produzione,.htaccess (meno punti di rottura); sui siti dei clienti dove l'hosting non permette di modificare la configurazione, il plugin. Il risultato su securityheaders.com è identico: A+ in entrambi i casi.

Devo configurare il CSP se il sito è su WordPress?

Per la maggior parte dei siti, no. Il CSP su WordPress richiede unsafe-inline e unsafe-eval per far funzionare Gutenberg e decine di plugin, il che riduce l'effetto protettivo a qualcosa di simbolico. Un CSP completo ha senso su progetti ad alto traffico con uno specialista di sicurezza dedicato che analizzerà ogni report di violazione. Per tutti gli altri, i 5 header di base forniscono la parte del leone della protezione pratica.

Come verifico che gli header funzionino dopo l'installazione?

Apri il sito in un browser, avvia DevTools (F12) → scheda Network → clicca sulla prima richiesta al tuo dominio → sezione Response Headers. Se vedi gli header aggiunti, tutto funziona. Per una verifica automatica, usa securityheaders.com: mostra non solo la presenza ma anche la correttezza dei valori, più un punteggio finale da A+ a F.

Cosa fare se l'hosting non permette di modificare.htaccess e non c'è accesso a functions.php?

Installa Headers Security Advanced & HSTS WP tramite il pannello di amministrazione di WordPress. Il plugin inietta gli header a livello PHP e non richiede la modifica dei file del server. Funziona su qualsiasi hosting dove gira WordPress, dal condiviso economico al Managed WordPress.

Gli header HTTP influenzano la velocità del sito?

Praticamente no. Gli header sono un paio di decine di byte di testo nella risposta del server. Non eseguono calcoli, non fanno query al database e non caricano la CPU. Il ritardo che aggiungono si misura in microsecondi. L'unica eccezione è il CSP con una allowlist complessa di centinaia di domini: il browser impiega tempo ad analizzarla, ma anche in questo caso l'impatto sulla velocità di rendering non supera un paio di millisecondi.

Cosa impostare e da dove iniziare

Gli header HTTP di sicurezza non sono un'azione una tantum "imposta e dimentica". Sono una base che dovrebbe essere presente su ogni sito per impostazione predefinita, come un certificato SSL.

Il piano per oggi:

• Controlla il tuo sito su securityheaders.com. Se il punteggio è D o F, non hai nemmeno X-Content-Type-Options.

• Aggiungi i 5 header di base usando uno dei tre metodi sopra. Se il sito è su Apache, via.htaccess (30 secondi). Nginx senza accesso alla configurazione, via functions.php (2 minuti). Se non vuoi toccare codice, il plugin Headers Security Advanced (3 minuti inclusa l'installazione).

• Ricontrolla il sito. Il punteggio dovrebbe salire a A o A+.

• Metti da parte il CSP. Tornaci una volta che gli header di base hanno funzionato per un mese senza problemi e hai tempo per testarlo in modalità Report-Only.

Un'ora e il tuo sito WordPress guadagna un livello di difesa che la stragrande maggioranza dei siti su internet non ha. Inizia subito con un controllo.