Cos'è HSTS (HTTP Strict Transport Security)?

HTTP Strict Transport Security (HSTS) è un meccanismo di sicurezza che istruisce i browser a comunicare con il tuo sito esclusivamente tramite HTTPS. Una volta che un browser ha ricevuto l'header HSTS dal tuo server, converte automaticamente ogni richiesta HTTP in HTTPS per il periodo specificato nell'header, anche se l'utente digita esplicitamente http:// nella barra degli indirizzi o clicca su un vecchio link HTTP.

Può sembrare una piccola comodità, ma risolve un problema reale e pericoloso. Vediamo esattamente perché HSTS esiste, come funziona in pratica e cosa devi sapere come proprietario di un sito WordPress.

Come funzionano gli attacchi SSL stripping senza HSTS

Immagina che un visitatore apra il suo laptop in un bar e digiti tuosito.com nel browser. Senza HSTS, il browser invia prima una normale richiesta HTTP al tuo server. Il tuo server risponde con un redirect 301 a https://tuosito.com. Quella prima richiesta HTTP è però completamente non cifrata. Viaggia in chiaro sulla rete wifi del bar.

Un aggressore sulla stessa rete può intercettare quella prima richiesta non cifrata tramite una tecnica chiamata SSL stripping. L'aggressore funge da proxy: mantiene una connessione HTTPS con il tuo vero server, ma serve una versione HTTP semplice alla vittima. Dalla prospettiva del visitatore, il sito appare normale (la maggior parte delle persone non controlla il lucchetto). Nel frattempo, l'aggressore può leggere tutto: credenziali di accesso, invii di moduli, cookie di sessione e dati di carte di credito.

Non è un attacco teorico. Strumenti come sslstrip sono pubblicamente disponibili dal 2009, e l'SSL stripping rimane uno degli attacchi più pratici sulle reti wifi pubbliche. HSTS è specificamente progettato per chiudere questa falla.

Come HSTS protegge il tuo sito WordPress

Quando il tuo server invia il seguente response header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

il browser memorizza questa istruzione internamente. Per i successivi 31.536.000 secondi (un anno), non tenterà mai una connessione HTTP con il tuo dominio. Se qualcosa prova a caricare una risorsa via HTTP, il browser la riscrive localmente in HTTPS prima che la richiesta lasci il dispositivo. Non c'è più alcuna richiesta non cifrata che un aggressore possa intercettare.

Questa protezione funziona a livello di browser, e questo è il vantaggio cruciale. Non serve alcun redirect. Non viene mai inviata una richiesta non cifrata. Il browser semplicemente rifiuta di usare HTTP per il tuo dominio.

Direttive dell'header HSTS spiegate

L'header HSTS accetta tre direttive, ognuna con uno scopo specifico:

• max-age: il tempo in secondi in cui il browser deve ricordare di imporre HTTPS. Valori comuni sono 86400 (1 giorno, utile per i test iniziali), 2592000 (30 giorni, un ragionevole punto di partenza) e 31536000 (1 anno, il valore di produzione consigliato). Impostandolo a zero, il browser smette immediatamente di imporre HSTS per il tuo dominio.
• includeSubDomains: estende la policy HSTS a tutti i sottodomini. Questo significa che cdn.tuosito.com, mail.tuosito.com e ogni altro sottodominio saranno anch'essi forzati a HTTPS. Fai attenzione con questa direttiva: se un sottodominio non supporta HTTPS, diventerà irraggiungibile una volta attivata.
• preload: un segnale che vuoi aggiungere il tuo dominio alle liste preload dei browser. Più dettagli sotto.

Il problema della prima visita e le liste HSTS preload

HSTS ha una limitazione fondamentale: il browser deve ricevere l'header almeno una volta prima di poter imporre qualcosa. Alla primissima visita, prima che il browser abbia mai visto il tuo header HSTS, la richiesta HTTP iniziale è ancora vulnerabile all'intercettazione. Questo è noto come "first visit problem" o "bootstrap problem".

La lista HSTS preload risolve questo. È una lista di domini hardcoded nel browser stesso (Chrome, Firefox, Safari ed Edge condividono tutti la stessa lista). Se il tuo dominio è nella lista preload, il browser impone HTTPS fin dalla primissima connessione, anche se l'utente non ha mai visitato il tuo sito prima.

Per inserire il tuo dominio nella lista preload, devi soddisfare tutti i seguenti requisiti:

• Servire un certificato HTTPS valido sul tuo dominio root
• Reindirizzare tutto il traffico HTTP verso HTTPS sullo stesso host
• Inviare l'header HSTS sul dominio root con un max-age di almeno 31536000 (un anno)
• Includere la direttiva includeSubDomains
• Includere la direttiva preload
• Tutti i sottodomini devono supportare HTTPS

Puoi inviare il tuo dominio su hstspreload.org. Tieni presente che l'inserimento può richiedere settimane o mesi (viene distribuito con gli aggiornamenti del browser) e la rimozione è altrettanto lenta. Assicurati che la tua configurazione HTTPS sia solida prima di inviare.

Valori max-age comuni e strategia di rollout consigliata

È allettante andare subito con un max-age di un anno, ma un rollout graduale è più sicuro, soprattutto per siti con più sottodomini o configurazioni complesse:

• max-age=300 (5 minuti): usalo durante i test iniziali. Se qualcosa va storto, i visitatori saranno bloccati su HTTPS solo per cinque minuti.
• max-age=86400 (1 giorno): un buon passo successivo una volta confermato che HTTPS funziona correttamente.
• max-age=2592000 (30 giorni): passa a questo dopo una o due settimane di funzionamento stabile.
• max-age=31536000 (1 anno): il valore di produzione consigliato. È anche il minimo richiesto per la lista preload.

Impostare HSTS su un sito WordPress

WordPress non invia l'header HSTS per default. Hai diverse opzioni per aggiungerlo:

L'approccio più affidabile è aggiungere l'header a livello di server. In Apache, aggiungi quanto segue al tuo file .htaccess o alla configurazione del virtual host:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Per Nginx, aggiungilo all'interno del tuo blocco server:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Se non hai accesso alla configurazione del server (comune sull'hosting condiviso), puoi aggiungere l'header tramite PHP nel functions.php del tuo tema o in un plugin must-use:

add_action('send_headers', function() {
    header('Strict-Transport-Security: max-age=31536000; includeSubDomains; preload');
});

L'approccio a livello di server è preferibile, perché si applica a tutte le risposte, inclusi file statici e pagine di errore, non solo alle pagine generate da PHP.

Diversi plugin di sicurezza WordPress offrono anche la configurazione HSTS tramite i loro pannelli di impostazioni, il che può essere utile se preferisci un approccio grafico.

Insidie comuni con HSTS su WordPress

Controlla alcune cose prima di abilitare HSTS:

• Mixed content: assicurati che tutte le risorse (immagini, script, fogli di stile, font) siano caricate tramite HTTPS. HSTS forza la connessione principale a HTTPS, ma se il tuo contenuto fa ancora riferimento a URL HTTP, i browser bloccheranno tali risorse.
• Rinnovo del certificato SSL: una volta che HSTS è attivo, un certificato scaduto rende il tuo sito completamente irraggiungibile (invece di mostrare un avviso bypassabile). Imposta il rinnovo automatico del certificato con Let's Encrypt o il tuo fornitore di certificati.
• Pronto per i sottodomini: se usi includeSubDomains, ogni sottodominio deve avere un certificato HTTPS valido. Un sottodominio di staging su HTTP smetterà di funzionare.
• Configurazione CDN: se usi un CDN come Cloudflare, assicurati che HSTS sia configurato in modo coerente. Cloudflare offre proprie impostazioni HSTS che possono sovrascrivere gli header del tuo server.

Cosa controlla InspectWP

InspectWP analizza se il tuo sito WordPress invia il response header Strict-Transport-Security. Il report valuta il valore di max-age, controlla la direttiva includeSubDomains e segnala l'assenza dell'header se non presente. Un header HSTS corretto con un valore max-age lungo (almeno sei mesi o un anno) e la direttiva includeSubDomains è consigliato per ogni sito WordPress in esecuzione su HTTPS, ovvero ogni sito nel web di oggi.