HSTS: la guida completa per attivare Strict-Transport-Security e la preload list

⚡TL;DR

• HSTS (RFC 6797) indica al browser di contattare un dominio solo in HTTPS per la durata definita da max-age, neutralizzando gli attacchi sslstrip e il downgrade di protocollo
• L'header si compone di tre direttive: max-age (obbligatoria), includeSubDomains (copre i sottodomini) e preload (opt-in alla lista integrata in Chrome e derivati)
• Per essere idoneo alla preload list servono max-age maggiore o uguale a 31 536 000, includeSubDomains, preload e una redirect HTTP verso HTTPS sul dominio apex
• La preload list è quasi irreversibile: una rimozione richiede diversi mesi e riguarda solo le versioni future dei browser
• Ad aprile 2026, circa 120 000 domini sono nella preload list di Chrome e solo il 35,7 % dei siti che hanno HSTS hanno attivato la direttiva preload

Nel 2009, Moxie Marlinspike presenta sslstrip al Black Hat DC. Lo strumento intercetta il traffico HTTP di un utente su una rete pubblica, sostituisce al volo ogni link e redirect HTTPS con il suo equivalente HTTP, poi inoltra le richieste in chiaro. L'utente crede di essere protetto da TLS, mentre tutto il suo traffico, inclusi cookie di sessione e password, viaggia in chiaro sul cavo. Nello stesso periodo, l'estensione Firefox Firesheep (ottobre 2010) rende popolare il furto di sessione su Facebook e Twitter da qualsiasi hotspot Wi-Fi aperto.

HSTS (HTTP Strict Transport Security) è la risposta a questi attacchi. Standardizzato dalla RFC 6797 nel novembre 2012, permette a un server HTTPS di indicare al browser che, per una durata definita, deve comunicare con il dominio solo in HTTPS. Quando l'header viene ricevuto e memorizzato, il browser converte localmente ogni richiesta http:// in https:// prima ancora di inviare un pacchetto sulla rete. La finestra di intercettazione durante la prima redirect scompare.

Ad aprile 2026, secondo gli studi di adozione AppSecSanta, solo il 35,7 % dei siti che inviano un header HSTS utilizza la direttiva preload. La Chrome HSTS Preload List contiene circa 120 000 domini, molto lontana dal parco HTTPS mondiale. HSTS resta quindi sottoutilizzato, spesso configurato male, talvolta attivato con effetti collaterali inattesi su sottodomini interni in HTTP.

Questa guida copre tre obiettivi: capire con precisione cosa fa HSTS (e cosa non fa), configurare l'header nei cinque stack web più comuni, e inviare correttamente un dominio alla preload list senza danneggiare l'infrastruttura. È rivolta a DevOps, SRE, amministratori di sistema e CTO di PMI che preparano un audit di sicurezza o un invio preload.

Che cos'è HSTS?

HSTS è un header di risposta HTTP inviato da un server HTTPS valido. Comunica allo user agent (browser, libreria HTTP, agente automatizzato compatibile con la RFC 6797) che il dominio deve essere contattato esclusivamente in HTTPS per la durata indicata dalla direttiva max-age.

Una volta che l'header è stato ricevuto su una connessione TLS valida, il browser registra localmente quello che viene chiamato un «Known HSTS Host». Per ogni richiesta successiva verso quel dominio, comprese quelle generate da un click su un link http://, da un segnalibro salvato o da una redirect 301 servita da un altro server, il browser riscrive l'URL in https:// prima dell'invio. La conversione avviene in memoria, lato client, senza alcuna richiesta di rete intermedia.

Tre elementi rendono HSTS efficace:

1. La conversione è locale. Nessuna richiesta HTTP viene mai emessa verso un dominio noto in HSTS. Un attaccante in posizione di man-in-the-middle vede solo TLS.
2. Gli errori di certificato sono fatali. Su un dominio in HSTS, il browser rimuove il pulsante «Continua comunque» che l'utente potrebbe cliccare su un errore TLS. Un certificato auto-firmato iniettato da un attaccante provoca un blocco, non un avviso.
3. Il TTL lato browser viene esteso a ogni visita. Finché l'utente visita il sito regolarmente, max-age viene rinfrescato a ogni risposta, il che impedisce la scadenza.

L'header è standardizzato e supportato da tutti i principali browser dal 2011. Chromium 4.0.211, Firefox 4.0 (agosto 2010), Opera 12, Safari su OS X 10.7.3, Edge fin dai suoi inizi e Internet Explorer 11 lo implementano. Ad aprile 2026 la compatibilità è universale: il 98 % del traffico web mondiale passa attraverso un browser compatibile con HSTS.

Il problema che HSTS risolve

sslstrip e il downgrade di protocollo

Senza HSTS, la protezione HTTPS di un sito presenta un anello debole: la prima richiesta. Quando un utente digita captaindns.com nella barra degli indirizzi, il browser emette di default una richiesta in HTTP sulla porta 80. Il server risponde con una redirect 301 verso https://captaindns.com. Questa prima richiesta viaggia in chiaro. Un attaccante sulla rete locale può intercettarla.

L'attacco sslstrip funziona così: l'attaccante si posiziona tra l'utente e il gateway di rete (ARP spoofing, rogue access point, compromissione DHCP). Intercetta la richiesta HTTP iniziale, la inoltra al server legittimo in HTTPS, riceve la risposta, sostituisce tutti gli https:// con http:// nell'HTML, negli header e nei cookie, poi la rimanda in chiaro all'utente. Dal punto di vista del browser, tutto sembra normale: una pagina HTTP classica, senza errori. L'utente inserisce la sua password, che transita in chiaro fino all'attaccante, poi viene inoltrata cifrata al server.

HSTS neutralizza sslstrip per le visite successive. Dopo la prima richiesta HTTPS riuscita, il browser memorizza l'header. La seconda visita, anche se inizia con un click su un link http:// o una redirect da un dominio terzo, non viaggia mai in HTTP. Il browser converte localmente l'URL prima del DNS, prima del connect(), prima di qualsiasi traffico di rete.

Il limite resta la primissima visita. Un browser che non ha mai ricevuto l'header HSTS per un dominio è vulnerabile a sslstrip sulla sua prima richiesta. È esattamente ciò che la preload list corregge: la lista integrata in Chrome permette al browser di conoscere i domini in HSTS fin dall'uscita di fabbrica, senza attendere una prima connessione.

Furto di cookie e Firesheep

Firesheep, pubblicato nell'ottobre 2010, ha dimostrato su larga scala la banalità del furto di sessione sulle reti pubbliche. L'estensione catturava i cookie di sessione di Facebook, Twitter, Flickr e di numerosi altri siti che servivano ancora i loro utenti autenticati in HTTP (o che passavano a HTTPS solo per la pagina di login per poi tornare a HTTP). Su un Wi-Fi di un bar, cliccare su un utente nell'interfaccia di Firesheep permetteva di accedere al suo account con un solo gesto.

HSTS rafforza la protezione dei cookie in due modi. Da un lato, imponendo HTTPS, elimina la fuga del cookie su una connessione non cifrata. Dall'altro, combinato con l'attributo Secure sul cookie (che ne vieta l'invio in HTTP) e HttpOnly (che blocca l'accesso JavaScript), chiude i tre vettori principali di furto di sessione di rete.

Con la direttiva includeSubDomains, HSTS protegge anche i cookie definiti senza specificare un dominio esplicito. Un cookie posto da www.captaindns.com senza Secure potrebbe, senza HSTS, essere inviato a api.captaindns.com in HTTP se vi fosse caricata una sottorisorsa in chiaro. Con includeSubDomains, tutte le richieste verso qualsiasi sottodominio vengono forzate in HTTPS, e il cookie resta cifrato.

Bootstrap MITM e la preload list

La RFC 6797 §14.6 riconosce esplicitamente la vulnerabilità del «bootstrap MITM»: un utente che visita un dominio per la prima volta non ha ancora ricevuto l'header HSTS, e la sua richiesta HTTP iniziale resta intercettabile. È la famosa finestra della prima visita.

La preload list di Chromium risolve questo problema integrando nel codice sorgente del browser la lista dei domini in HSTS. Chrome, Firefox, Safari ed Edge importano questa lista a ogni aggiornamento. Per un dominio presente, il browser sa che deve usare HTTPS fin dalla primissima richiesta, anche senza aver mai visitato il sito. La finestra di bootstrap scompare.

L'iscrizione è gratuita ma esigente: max-age maggiore o uguale a 1 anno, includeSubDomains, preload, redirect HTTP verso HTTPS sul dominio apex. Una volta iscritto, la rimozione richiede diversi mesi, perché bisogna attendere che tutte le versioni distribuite dei browser importino la nuova lista. Alcuni utenti su versioni vecchie continueranno a forzare HTTPS sul tuo dominio per anni.

Anatomia dell'header Strict-Transport-Security

La sintassi è definita dalla RFC 6797 §6.1. L'header si compone di una direttiva obbligatoria (max-age) e di due direttive opzionali (includeSubDomains, preload), separate da punti e virgola.

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

Le direttive sono insensibili al maiuscolo/minuscolo (IncludeSubDomains è valido ma non canonico). Una direttiva sconosciuta viene silenziosamente ignorata dai browser conformi. Se la sintassi complessiva è invalida, l'header intero viene rifiutato: un solo errore di battitura può disattivare la tua protezione senza alcun avviso visibile. Da qui l'importanza di testare la configurazione con uno strumento dedicato prima di metterla in produzione.

Regole di validità

Diverse regole rigide della RFC 6797 influenzano il deployment:

• HTTPS obbligatorio. Un header HSTS ricevuto via HTTP viene ignorato (§8.1). Questa regola è cruciale: impedisce a un attaccante man-in-the-middle di iniettare un max-age=0 in HTTP per disattivare HSTS sulla vittima.
• Certificato valido obbligatorio. L'header viene preso in considerazione solo se la connessione TLS si è stabilita senza errori né avvisi (§8.1). Un certificato scaduto, un nome di dominio errato, una catena incompleta: tutto questo impedisce la memorizzazione.
• Solo la prima occorrenza. Se più header HSTS vengono inviati nella stessa risposta, viene processato solo il primo (§8.1). Attenzione ai middleware, CDN e reverse proxy che impilano i propri header.
• Niente indirizzi IP. HSTS si applica solo ai nomi di dominio. Un sito accessibile via https://192.168.1.1 non è coinvolto (§8.3).
• Tutte le porte. HSTS copre il dominio per tutte le porte. Una porta 80 viene automaticamente convertita in 443, ma una porta personalizzata resta sul suo numero.

Tre esempi canonici

# Minimo praticabile: 1 anno, senza sottodomini
Strict-Transport-Security: max-age=31536000

# Raccomandazione OWASP: 1 anno con sottodomini
Strict-Transport-Security: max-age=31536000; includeSubDomains

# Idoneo preload list: 2 anni con sottodomini e opt-in preload
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

La terza riga è la configurazione obiettivo per ogni sito pubblico che desideri una protezione massima. La approfondiamo sezione per sezione.

max-age: la durata della policy

max-age è l'unica direttiva obbligatoria. Esprime in secondi il tempo durante il quale il browser deve considerare il dominio come «Known HSTS Host». Alcuni valori tipici:

Valore	Durata	Uso
0	Immediato	Rimozione della policy HSTS
300	5 minuti	Test iniziale, rollout cauto
3600	1 ora	Staging, validazione breve
86 400	1 giorno	Rollout progressivo, J+1
604 800	1 settimana	Rollout progressivo, settimana 1
31 536 000	1 anno	Soglia minima preload list (dall'11 ottobre 2017)
63 072 000	2 anni	Raccomandazione comune per preload

Il contatore viene resettato a ogni risposta HTTPS che contiene l'header. In concreto, se il tuo sito invia max-age=31536000 e un utente visita una pagina al mese, la policy non si spegne mai finché torna nell'arco dell'anno. Al contrario, se rimuovi bruscamente l'header, i browser che hanno ricevuto la policy continueranno a forzare HTTPS fino alla scadenza locale. È un effetto cricchetto: HSTS è facile da attivare in un solo verso.

Rollout progressivo raccomandato

OWASP e cio.gov raccomandano un'attivazione progressiva per evitare di trovarsi bloccati con una policy di un anno su un sito ancora in distribuzione. Un piano tipo:

1. Giorno 0: max-age=300. 5 minuti. Verifica che la catena HTTPS funzioni, che la redirect HTTP verso HTTPS sia stabile, che tutti i contenuti interni siano serviti in HTTPS. Una rimozione è banale, la policy scade in 5 minuti.
2. Giorno 1: max-age=86 400. 1 giorno. Osserva gli errori TLS riportati dal tuo sistema di monitoring, dal tuo WAF e dai tuoi log applicativi per 24 ore. Sorveglia in particolare le redirect rotte verso risorse interne.
3. Giorno 7: max-age=604 800. 1 settimana. Se il tasso di errore TLS resta stabile, passa a una settimana. Questa fase verifica che tutti i sottodomini attivi siano accessibili in HTTPS.
4. Giorno 14: max-age=31 536 000. 1 anno. La policy è stabile, gli utenti sono protetti. Se punti alla preload list, puoi attivare includeSubDomains e preload in questa fase dopo un audit.

Questo ritmo permette di tornare indietro a ogni passo. Saltare direttamente a 1 anno senza test intermedi è l'errore più frequente: se un solo sottodominio dimenticato si rompe dopo l'attivazione di includeSubDomains, sei bloccato per un anno lato browser.

Disattivazione tramite max-age=0

La RFC 6797 §6.1.1 precisa che un valore di 0 segnala al browser di rimuovere la policy in cache. È l'unico modo per togliere HSTS in modo pulito: servire per la durata precedente un header con max-age=0, attendere che i browser ricevano questo aggiornamento, poi rimuovere completamente l'header. Attenzione, questa disattivazione è effettiva solo su HTTPS (§8.1). Un max-age=0 servito in HTTP viene ignorato.

includeSubDomains: estendere la protezione

La direttiva includeSubDomains estende la policy HSTS a tutti i sottodomini del nome host che l'ha inviata. Inviata da captaindns.com, copre www.captaindns.com, api.captaindns.com, blog.captaindns.com, così come tutti i sotto-sottodomini (staging.api.captaindns.com, ecc.).

La RFC 6797 §8.2 precisa che il matching avviene label per label, da destra a sinistra, insensibile al maiuscolo/minuscolo. Una policy HSTS dichiarata su captaindns.com copre quindi tutta la gerarchia DNS sottostante. Al contrario, una policy dichiarata su www.captaindns.com non copre né api.captaindns.com né captaindns.com, perché la radice non è un sottodominio di www.

Perché è critico per i cookie

Senza includeSubDomains, un attaccante può aggirare HSTS forzando una richiesta HTTP verso un sottodominio. Scenario classico:

1. L'utente si connette a https://captaindns.com protetto da HSTS, riceve un cookie di sessione senza attributo Secure.
2. L'attaccante inietta un'immagine <img src="http://blog.captaindns.com/pixel.png"> in una pagina visitata dalla vittima (tramite XSS, un forum, o un man-in-the-middle su un altro sito).
3. Il browser emette la richiesta in HTTP verso blog.captaindns.com e vi allega automaticamente il cookie del dominio padre (perché i cookie si propagano ai sottodomini).
4. L'attaccante, posizionato sulla rete, cattura il cookie in chiaro.

Con includeSubDomains, la richiesta verso blog.captaindns.com viene convertita in HTTPS prima dell'invio. Il cookie resta cifrato sul cavo. Per questo motivo l'OWASP Cheat Sheet raccomanda sistematicamente includeSubDomains non appena possibile.

Le trappole da evitare

includeSubDomains ha un effetto collaterale radicale: tutti i sottodomini, compresi quelli non pubblici, devono servire HTTPS. Ecco le trappole più frequenti, documentate dalle community DevOps:

• Strumenti interni in HTTP. Un grafana.interno.captaindns.com servito in HTTP sulla rete privata diventerà inaccessibile agli utenti che hanno già memorizzato la policy HSTS di captaindns.com.
• Ambienti di staging. Uno staging.captaindns.com con un certificato auto-firmato provoca errori TLS fatali per i team che si connettono da postazioni che hanno visitato la produzione.
• Sottodomini storici. Un vecchio mail.captaindns.com servito da un fornitore terzo in HTTP rischia di rompere i link nelle vecchie email.
• Sottodomini di terze parti. Un sottodominio delegato a un fornitore SaaS (support.captaindns.com che punta a Zendesk per esempio) deve offrire HTTPS con un certificato valido per il nome delegato.

Prima di attivare includeSubDomains, fai un inventario esaustivo. I team più esperti passano per una fase di «shadow mode»: attivare HSTS senza includeSubDomains per diverse settimane, correlare con i log DNS per identificare i sottodomini attivi, passare al cambio solo dopo un audit completo.

Alternativa: HSTS a livello di sottodominio

Se alcuni sottodomini non possono essere passati in HTTPS (legacy, contratto esterno), un'alternativa è dichiarare HSTS individualmente su ogni sottodominio che lo può fare, senza includeSubDomains a livello root. È più verboso ma evita di rompere i sottodomini in HTTP. Il costo: ogni sottodominio deve mantenere la propria policy, e non puoi essere idoneo alla preload list senza includeSubDomains sull'apex.

preload: la lista integrata

La direttiva preload è un opt-in con cui il proprietario del dominio dichiara la propria intenzione di figurare nella Chrome HSTS Preload List. Senza questa direttiva, il dominio non sarà accettato in fase di invio, anche se soddisfa tutti gli altri criteri.

Le quattro condizioni di idoneità

hstspreload.org richiede, dall'11 ottobre 2017, che l'header servito dal dominio apex rispetti quattro condizioni:

1. max-age maggiore o uguale a 31 536 000 (1 anno). Un max-age più breve viene rifiutato.
2. includeSubDomains presente. La preload list copre sempre l'intero albero DNS.
3. preload presente. Dichiarazione esplicita di intenzione.
4. Redirect HTTP verso HTTPS sul dominio apex. Se il server accetta connessioni sulla porta 80, deve restituire un 301 verso HTTPS. Anche la redirect deve servire l'header HSTS.

Sono richiesti anche un certificato TLS valido e la capacità di servire tutti i sottodomini (incluso www) in HTTPS. Lo strumento di invio testa automaticamente queste condizioni prima di accettare la richiesta.

Il processo di invio

Una volta soddisfatte le condizioni, l'invio avviene in tre fasi:

1. Test automatico. Su hstspreload.org, inserisci il tuo dominio. Il servizio testa l'header HSTS, la redirect HTTP verso HTTPS, la disponibilità HTTPS dei sottodomini www. Gli errori sono dettagliati.
2. Invio. Se il test passa, un pulsante «Submit to the HSTS preload list» diventa disponibile. Conferma dopo aver letto gli avvisi sull'irreversibilità.
3. Integrazione. Il dominio passa allo stato pending. Viene integrato nella lista sorgente di Chromium, propagata a Firefox, Safari, Edge. La propagazione completa richiede circa 6-12 settimane, a seconda dei cicli di release dei browser.

Puoi verificare lo stato in qualsiasi momento tramite curl https://hstspreload.org/api/v2/status?domain=captaindns.com.

L'irreversibilità

È il punto più importante da capire. Una volta nella preload list, una rimozione richiede diversi mesi e riguarda solo le versioni future dei browser. Gli utenti su una versione vecchia continueranno a forzare HTTPS sul tuo dominio per anni. È particolarmente fastidioso in tre casi:

• Vendita del dominio. Se cedi captaindns.com a un terzo che desidera utilizzarlo in HTTP, il tuo opt-in glielo impedirà.
• Dismissione dell'infrastruttura. Se interrompi un servizio e il dominio viene riutilizzato per qualcos'altro, HSTS resta in cache.
• Rollback d'urgenza. Se un attacco o un incidente corrompe la tua catena TLS, non puoi disattivare HTTPS in emergenza.

La pagina hstspreload.org/removal/ documenta la procedura di rimozione. Avvisa esplicitamente che il processo può richiedere diversi mesi e che alcuni utenti non vedranno mai la rimozione.

Adozione reale ad aprile 2026

Lo studio APNIC 2023 e i dati 2026 mostrano che l'adozione resta bassa nonostante i benefici:

Statistica	Valore
Domini nella preload list	~120 000
Dimensione del file integrato	~18 MB
Siti con HSTS che attivano preload	35,7 %
Top 20 mondiale nella preload list	8 su 20
Adozione finanza / banche	Molto bassa

Google, GitHub, Twitter, Facebook, PayPal figurano nella lista. Al contrario, la metà dei 20 maggiori siti mondiali non ha HSTS sul dominio apex. I settori regolamentati (finanza, sanità) sono in ritardo, spesso per conservatorismo sulla reversibilità.

Guida passo passo: attivare HSTS per stack

Copriamo qui i cinque ambienti più diffusi nel 2026. Per ogni stack, la configurazione fornisce prima il minimo praticabile, poi la versione idonea preload.

Nginx

In Nginx, l'header HSTS viene emesso tramite la direttiva add_header nel blocco server che ascolta sulla porta 443. Il parametro always è essenziale: senza, Nginx aggiunge l'header solo sulle risposte 2xx e 3xx, e lo dimentica sulle 4xx e 5xx. Un attaccante potrebbe quindi forzare un errore 404 per aggirare la protezione.

Configurazione minima:

server {
    listen 443 ssl http2;
    server_name captaindns.com;

    ssl_certificate /etc/letsencrypt/live/captaindns.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/captaindns.com/privkey.pem;

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

    # resto della configurazione
}

Configurazione idonea preload:

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

Attenzione ai blocchi annidati. Nginx applica add_header solo al livello più specifico che contiene un add_header. Se dichiari HSTS a livello server poi ridichiari un altro add_header in un blocco location, l'HSTS del livello server scompare su quella location. La soluzione: ripetere la direttiva HSTS in ogni location o usare more_set_headers del modulo nginx_headers_more.

Il blocco di ascolto sulla porta 80 deve effettuare la redirect 301 verso HTTPS:

server {
    listen 80;
    server_name captaindns.com www.captaindns.com;
    return 301 https://$host$request_uri;
}

Non aggiungere mai l'header HSTS in questo blocco porta 80. I browser lo ignorano (RFC 6797 §8.1), ma la presenza confonde gli audit e segnala una configurazione approssimativa.

Apache HTTPD

Apache gestisce HSTS tramite il modulo mod_headers. Su Debian e derivati, attivalo con sudo a2enmod headers poi sudo systemctl reload apache2. La direttiva Header always set scrive l'header su tutte le risposte, errori inclusi.

Configurazione minima in /etc/apache2/sites-available/captaindns.com.conf o in un .htaccess alla radice del sito:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

Configurazione idonea preload:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Come per Nginx, l'header deve essere posizionato unicamente nel VirtualHost che ascolta sulla porta 443. Il VirtualHost porta 80 deve contenere una redirect verso HTTPS, tipicamente tramite mod_rewrite o la direttiva Redirect permanent:

<VirtualHost *:80>
    ServerName captaindns.com
    ServerAlias www.captaindns.com
    Redirect permanent / https://captaindns.com/
</VirtualHost>

Anche il posizionamento in .htaccess funziona, il che è utile per l'hosting condiviso. Bisogna comunque verificare che la direttiva AllowOverride autorizzi Headers nella configurazione del server.

Cloudflare

Cloudflare propone una gestione nativa di HSTS nella sua dashboard. Due vantaggi: nessuna modifica della configurazione server, e Cloudflare serve l'header su tutte le risposte che attraversano la CDN, comprese le pagine di errore gestite lato edge.

Per attivare HSTS su Cloudflare:

1. Accedi alla dashboard Cloudflare e seleziona il dominio.
2. Vai in SSL/TLS poi Edge Certificates.
3. Scorri fino a HTTP Strict Transport Security (HSTS) e clicca su Enable HSTS.
4. Leggi l'avviso, spunta «I understand», poi Next.
5. Configura le opzioni:
   • Max Age: scegli minimo 12 mesi (18 o 24 mesi per preload).
   • Apply HSTS policy to subdomains: attiva includeSubDomains.
   • Preload: attiva la direttiva preload.
   • No-Sniff Header: aggiunge X-Content-Type-Options: nosniff (raccomandato).
6. Clicca Save.

Cloudflare aggiunge immediatamente l'header a tutte le risposte. Verifica tramite curl -I https://captaindns.com che l'header sia effettivamente presente.

Attenzione: Cloudflare serve HSTS anche se la tua origin è in HTTP dietro Cloudflare. È una trappola classica: puoi rendere il tuo sito idoneo alla preload list mentre l'origin è tecnicamente insicura. Se un giorno cambi CDN o passi a DNS Only, i visitatori finiranno su un'origin HTTP bloccata da HSTS. Prima di attivare preload tramite Cloudflare, assicurati che la tua origin sia realmente in HTTPS.

AWS CloudFront

CloudFront gestisce HSTS tramite le Response Headers Policies, introdotte nel 2021. Puoi usare una policy gestita da AWS (Managed-SecurityHeadersPolicy) o creare una policy custom per un controllo fine.

Tramite la console AWS:

1. CloudFront → Policies → Response headers → Create response headers policy.
2. Sezione Strict-Transport-Security: attiva la casella.
3. Compila:
   • Max-age (seconds): 63072000 per preload, 31536000 altrimenti.
   • Include subdomains: spunta per preload.
   • Preload: spunta per preload.
   • Override origin: spunta affinché CloudFront sovrascriva l'header eventualmente inviato dall'origin (raccomandato).
4. Crea la policy, poi associala alla tua distribuzione CloudFront nella scheda Behaviors.

Tramite Terraform:

resource "aws_cloudfront_response_headers_policy" "security" {
  name = "captaindns-security-headers"

  security_headers_config {
    strict_transport_security {
      access_control_max_age_sec = 63072000
      include_subdomains         = true
      preload                    = true
      override                   = true
    }
  }
}

resource "aws_cloudfront_distribution" "captaindns" {
  # ...
  default_cache_behavior {
    # ...
    response_headers_policy_id = aws_cloudfront_response_headers_policy.security.id
  }
}

Il vantaggio di una Response Headers Policy rispetto a una CloudFront Function è il costo: gratuito, nessuna fatturazione per richiesta.

Caddy

Caddy si distingue: non fornisce HSTS di default, volutamente. Matt Holt, il suo creatore, ritiene che un'attivazione automatica sarebbe pericolosa per gli utenti che potrebbero voler rimuovere HTTPS più tardi.

L'attivazione manuale è semplice, tramite la direttiva header nel Caddyfile:

captaindns.com {
    tls admin@captaindns.com

    header {
        Strict-Transport-Security "max-age=31536000"
    }

    # resto della configurazione
}

Per la versione preload:

captaindns.com {
    tls admin@captaindns.com

    header {
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    }
}

Caddy gestisce automaticamente la redirect HTTP verso HTTPS, e rinnova i suoi certificati Let's Encrypt in background. Puoi quindi attivare HSTS con fiducia fin dal giorno 1, poiché Caddy garantisce la disponibilità HTTPS sul lungo periodo.

Per un reverse proxy, lo schema è identico, ma piazza la direttiva header nel blocco che serve il front:

captaindns.com {
    header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    reverse_proxy localhost:3000
}

Procedere al precaricamento HSTS

Una volta che l'header HSTS è stabile sul tuo dominio apex con le tre direttive, puoi inviarlo alla preload list. Non affrettare questa fase: la decisione è quasi irreversibile.

Checklist prima dell'invio

Scorri questa lista. Ogni casella deve essere spuntata.

• Tutti i sottodomini pubblici (www, api, mail, blog, shop) servono HTTPS con un certificato valido.
• Tutti i sottodomini interni (staging, admin, monitoring, ci) servono HTTPS o sono chiusi all'esterno.
• Il dominio apex serve https:// con un certificato il cui SAN copre bene l'apex.
• La redirect HTTP verso HTTPS sul dominio apex restituisce un 301 (non un 302).
• L'header HSTS sull'apex contiene max-age=31536000 (o più), includeSubDomains e preload.
• La catena TLS è completa (nessun certificato intermedio mancante).
• Non hai un sottodominio gestito da terze parti che potrebbe non supportare HTTPS (es: un vecchio blog in HTTP presso un hosting legacy).
• Hai vissuto almeno 30 giorni con la configurazione finale per intercettare i casi limite.

Fai eseguire il test automatico su hstspreload.org. Se appare una spia rossa, correggi prima di inviare. Gli errori tipici: certificato auto-firmato su www, redirect 302 invece di 301, header HSTS assente sulla risposta 301 dell'HTTP.

Inviare il dominio

Una volta che il test è verde, clicca sul pulsante di invio, inserisci il tuo indirizzo email e conferma. Il dominio passa allo stato pending. Entro 3-4 settimane, viene integrato nel codice sorgente di Chromium. Entro 6-12 settimane, è presente nelle versioni stabili di Chrome, Firefox, Safari ed Edge.

Puoi seguire lo stato:

curl "https://hstspreload.org/api/v2/status?domain=captaindns.com"

Gli stati possibili: unknown (sconosciuto), pending (in attesa), preloaded (integrato), rejected (rifiutato, vedi dettagli).

Mantenere la policy dopo l'invio

Mantieni l'header HSTS con le tre direttive in modo permanente. Alcune aziende rimuovono preload dopo l'invio credendo che sia finita: è un errore. La presenza continua della direttiva viene verificata durante gli audit periodici della preload list da parte del team Chromium, e la sua assenza può comportare una rimozione.

Rimuovere un dominio (procedura lunga)

Se devi rimuovere il tuo dominio dalla preload list:

1. Vai su hstspreload.org/removal/.
2. Fornisci le motivazioni (vendita del dominio, migrazione di infrastruttura, ecc.).
3. Servi max-age=0 sul tuo dominio durante il periodo di rimozione.
4. Attendi 4-12 settimane per l'integrazione in Chromium.
5. Attendi altri 6-12 mesi affinché la maggioranza degli utenti aggiorni il proprio browser.

Durante questo periodo, il tuo dominio resta forzato in HTTPS nella maggior parte dei browser. Pianifica la procedura prima di non poter più servire TLS.

Errori frequenti e anti-pattern

Attivare HSTS senza aver testato la catena HTTPS

È l'errore più costoso. Attivare max-age=31536000 senza aver verificato che tutti gli endpoint servano correttamente HTTPS blocca gli utenti per un anno. Comincia sempre da max-age=300 e progredisci a tappe.

Dimenticare always in Nginx

Senza always, add_header viene emesso solo sulle risposte 2xx/3xx. Su una pagina di errore 500 o 404, l'header HSTS scompare. Se quella pagina è la prima vista da un nuovo visitatore, la policy non viene memorizzata. Un attaccante può sfruttare questa falla.

Inviare HSTS in HTTP

Tecnicamente, i browser ignorano l'header ricevuto in HTTP (RFC §8.1). In pratica, questo segnala una configurazione approssimativa e disturba gli audit. Invia HSTS solo nei blocchi HTTPS.

Cookie senza attributo Secure

HSTS forza HTTPS a livello browser, ma su un browser non compatibile o sulla prima visita, un cookie senza Secure può fuoriuscire. Combina sistematicamente HSTS e Set-Cookie: ... ; Secure; HttpOnly; SameSite=Lax.

Preload senza includeSubDomains

Tecnicamente impossibile: il servizio hstspreload.org rifiuta ogni invio senza includeSubDomains. Alcune configurazioni distribuite attivano preload senza includeSubDomains. Risultato: l'header viene servito ma il dominio non viene mai integrato, il che crea una falsa impressione di protezione.

Certificato auto-firmato su staging

Uno sviluppatore si connette a staging.captaindns.com servito da un certificato auto-firmato, poi visita la produzione captaindns.com. Dopo l'attivazione di HSTS con includeSubDomains, lo sviluppatore non può più accedere allo staging: il browser rifiuta il certificato auto-firmato. Soluzione: usa un certificato Let's Encrypt tramite un DNS challenge, o piazza lo staging su un dominio dedicato non coperto dalla policy.

Redirect 302 invece di 301

Il test preload richiede un 301 «Moved Permanently» sulla redirect HTTP verso HTTPS. Un 302 «Found» viene rifiutato. Verifica con curl -I http://captaindns.com.

Assenza di HSTS sulla risposta di redirect

Quando il browser riceve la prima risposta 301 in HTTP, segue la redirect verso HTTPS. È la seconda risposta (in HTTPS) che deve contenere HSTS. Alcune configurazioni, per dimenticanza, piazzano HSTS sulla redirect HTTP (senza effetto) e lo dimenticano sul target HTTPS.

HSTS in un meta tag HTML

HSTS è un header HTTP, non un elemento HTML. <meta http-equiv="Strict-Transport-Security" content="..."> viene ignorato da tutti i browser. Invia sempre l'header lato server.

Dimenticare di testare dopo un cambio di infrastruttura

Dopo una migrazione verso una nuova CDN, un cambio di reverse proxy o un aggiornamento di Terraform, l'header HSTS può sparire silenziosamente. Integra un test automatizzato nella tua CI/CD che verifichi la presenza dell'header su tutte le route principali.

Verifica la tua configurazione HSTS con CaptainDNS

Da CaptainDNS forniamo uno strumento dedicato per fare l'audit della tua configurazione HSTS in 3 secondi, senza account né registrazione: il test HSTS di CaptainDNS.

Lo strumento effettua tre verifiche in parallelo:

1. Analisi dell'header Strict-Transport-Security: lo strumento interroga il dominio in HTTPS, cattura l'header e analizza le sue direttive. Rileva max-age, includeSubDomains, preload, così come i valori tra virgolette o malformati che alcuni server restituiscono.
2. Interrogazione della preload list di Chrome: tramite l'API hstspreload.org, recupera lo stato reale del tuo dominio (unknown, pending, preloaded, rejected) e l'idoneità all'invio.
3. Calcolo di un grade attuabile: il risultato è riassunto da un grade tra cinque livelli: missing (nessun header), weak (max-age troppo basso), good (max-age sufficiente), preload-ready (idoneo ma non inviato), preloaded (nella lista Chrome).

Per ogni grade inferiore a preloaded, lo strumento fornisce gli snippet di configurazione pronti da incollare per Nginx, Apache e Cloudflare. Dopo aver distribuito la correzione, rilancia il test per confermare il passaggio al grade superiore.

Per una vista più ampia dei tuoi header di sicurezza (CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy), usa anche il nostro Headers Viewer, che mostra la lista fedele degli header nel loro ordine di arrivo. Per testare la tua redirect HTTP verso HTTPS, il Redirect Checker segue la catena completa di redirect.

Se il tuo obiettivo va oltre HSTS e copre la sicurezza TLS del parco email, consulta il nostro verificatore di certificati TLS per ispezionare i certificati TLS o il check DANE/TLSA per aggiungere una verifica DANE/TLSA sui tuoi server di posta.

FAQ

Che cos'è HSTS, in una frase?

HSTS è un header di risposta HTTP che indica al browser di contattare un dominio solo in HTTPS per la durata indicata dalla direttiva max-age, neutralizzando gli attacchi che tentano di forzare una connessione in chiaro.

Perché il mio sito segna «HSTS missing» su un test?

Tre cause sono possibili: l'header non viene inviato affatto, viene inviato solo in HTTP (quindi ignorato dai browser), oppure viene inviato in HTTPS ma con una sintassi invalida. Usa uno strumento come il test HSTS di CaptainDNS per isolare il problema preciso.

Quale valore di max-age scegliere?

Per un rollout cauto, parti da max-age=300 (5 minuti), poi sali progressivamente a tappe (1 giorno, 1 settimana, 1 anno). Per una produzione stabile, max-age=31536000 (1 anno) è il minimo raccomandato. Per la preload list, max-age=63072000 (2 anni) è il valore più comune. Oltre, non c'è alcun guadagno di sicurezza supplementare.

HSTS protegge la primissima visita?

No. Senza preload list, un browser che visita il tuo dominio per la prima volta emette una richiesta HTTP prima di ricevere l'header HSTS. Questa finestra di bootstrap resta vulnerabile a un attacco man-in-the-middle. La preload list di Chrome risolve questo problema integrando la lista dei domini noti nel codice sorgente del browser.

Posso attivare HSTS senza includeSubDomains?

Sì, ma la protezione è meno robusta. includeSubDomains copre in particolare i cookie definiti a livello del dominio padre. Senza questa direttiva, un attaccante può forzare una richiesta HTTP verso un sottodominio non HTTPS per catturare i cookie. Se tutti i tuoi sottodomini possono servire HTTPS, attivala. Altrimenti, accetta una protezione parziale.

Cosa succede se disattivo HSTS per errore?

Niente di visibile lato utente finché la policy precedentemente ricevuta non è scaduta. Il browser continua a forzare HTTPS fino alla fine di max-age. Per disattivare correttamente, servi max-age=0 per la durata equivalente al tuo vecchio max-age (almeno 1 anno in produzione stabile), poi rimuovi completamente l'header.

Come testare HSTS in locale senza inquinare il mio browser?

Usa un dominio di test dedicato (per esempio un dominio .test riservato dall'IETF o un secondo livello distinto dalla tua produzione) con un certificato Let's Encrypt ottenuto tramite DNS challenge. Evita di testare HSTS sul tuo dominio di produzione dalla tua postazione: una configurazione errata può bloccarti per tutta la durata di max-age. In sviluppo, puoi anche svuotare la cache HSTS di Chrome tramite chrome://net-internals/#hsts, scheda «Delete domain security policies».

Bisogna togliere HSTS da un sito che non fa più HTTPS?

No, non puoi togliere HSTS semplicemente. Una volta che un browser ha memorizzato la policy, rifiuterà ogni connessione HTTP fino alla scadenza di max-age. Prima di migrare un sito verso HTTP (cosa sconsigliata), devi servire max-age=0 in HTTPS per la durata precedente e attendere la scadenza nei browser dei tuoi visitatori.

La preload list è reversibile?

Tecnicamente sì, in pratica no. La procedura di rimozione su hstspreload.org richiede 4-12 settimane per l'integrazione in Chromium, poi altri 6-12 mesi affinché la maggioranza degli utenti aggiorni il proprio browser. Alcuni utenti non vedranno mai la rimozione. Prima di inviare alla preload list, assicurati di poter mantenere HTTPS su questo dominio per anni.

HSTS sostituisce la redirect 301 HTTP verso HTTPS?

No, la completa. La redirect 301 è necessaria per la primissima visita e per gli utenti che non hanno mai ricevuto l'header HSTS. HSTS prende il sopravvento per le visite successive convertendo gli URL lato browser prima dell'invio in rete. I due meccanismi devono coesistere.

Quanti siti sono nella preload list nel 2026?

Circa 120 000 domini sono iscritti nella preload list di Chromium ad aprile 2026. Il file sorgente pesa circa 18 MB. Tra questi domini si trova la maggioranza dei grandi attori tech (Google, GitHub, Twitter, Facebook, PayPal) ma solo la metà dei 20 maggiori siti mondiali. I settori finanza, sanità e amministrazione restano molto in ritardo.

Conclusione: HSTS, la base indispensabile di ogni infrastruttura HTTPS

HSTS è il pezzo mancante di una configurazione HTTPS robusta. Senza di esso, la primissima richiesta di ogni visita viaggia in chiaro sulla rete, e tutto il resto del traffico dipende dal corretto svolgimento della redirect 301. Con esso, il browser prende il controllo e converte localmente ogni URL prima ancora che il resolver DNS venga consultato.

Tre punti da ricordare:

1. Attiva HSTS progressivamente. Comincia con max-age=300 per validare la tua catena HTTPS, poi sali a tappe nell'arco di 2-4 settimane. Sorveglia gli errori TLS a ogni tappa.
2. Aggiungi includeSubDomains non appena i tuoi sottodomini sono pronti. Questa direttiva chiude la porta agli attacchi via sottodominio e protegge i tuoi cookie in profondità. Fai un inventario esaustivo prima di attivarla.
3. Considera la preload list per la protezione massima. Neutralizza la vulnerabilità del bootstrap MITM, ma è un impegno quasi irreversibile. Inviala solo dopo 30 giorni di stabilità in produzione.

Per testare la tua configurazione HSTS subito, vai su il test HSTS gratuito di CaptainDNS. Lo strumento calcola il tuo grade, analizza le tue direttive, interroga la preload list di Chrome e ti fornisce gli snippet Nginx, Apache e Cloudflare pronti da incollare. Nessun account richiesto, risultato in 3 secondi.