HSTS (HTTP Strict Transport Security) è un'intestazione HTTP di risposta definita dall'RFC 6797. Indica al browser di contattare il dominio solo in HTTPS per la durata indicata dalla direttiva max-age. Una volta memorizzata l'intestazione, il browser converte automaticamente ogni richiesta http:// in https:// prima dell'invio, impedendo i downgrade e gli attacchi di tipo SSL stripping sulle reti non controllate.

Test HSTS e preload: verifica la tua intestazione HTTPS

Perché testare HSTS?

L'intestazione HSTS è uno dei controlli di sicurezza HTTPS più efficaci, ma è spesso configurato male: max-age troppo corto, includeSubDomains dimenticato, o un dominio idoneo alla preload list ma mai inviato. Testare regolarmente la tua configurazione permette di rilevare queste lacune prima che vengano sfruttate.

Tre casi d'uso principali:

Audit di sicurezza prima della messa in produzione: validare che la catena HTTPS, il redirect HTTP verso HTTPS e l'intestazione Strict-Transport-Security siano coerenti prima di aprire un nuovo dominio al pubblico.
Preparazione alla preload list: verificare i quattro requisiti (max-age maggiore o uguale a 31536000, includeSubDomains, preload, redirect HTTP verso HTTPS) prima di inviare il dominio a hstspreload.org.
Verifica post-migrazione: dopo un cambio di infrastruttura (passaggio a Cloudflare, migrazione a un nuovo cluster Nginx), confermare che l'intestazione HSTS sia ancora inviata con le direttive corrette sul dominio principale e sui sottodomini.

Come usare il test HSTS in 3 passi

Passo 1: Inserire il dominio

Digita il dominio principale senza https:// né path (ad esempio captaindns.com). Lo strumento punta automaticamente alla versione HTTPS del sito e segue il redirect iniziale se presente. Evita i sottodomini nella prima analisi, salvo che il tuo obiettivo sia verificare un servizio specifico (ad esempio api.captaindns.com).

Passo 2: Avviare il test HSTS

Clicca su Testa. CaptainDNS esegue tre azioni in parallelo: interrogazione dell'intestazione Strict-Transport-Security restituita dal server, richiesta alla preload list di Chrome per confermare lo stato e analisi delle direttive max-age, includeSubDomains e preload. Il risultato completo appare in meno di 3 secondi.

Passo 3: Applicare le raccomandazioni

Leggi il tuo grado (missing, weak, good, preload-ready o preloaded) e l'elenco delle correzioni proposte. Copia lo snippet Nginx, Apache o Cloudflare adatto al tuo stack, distribuiscilo, poi rilancia il test per confermare il passaggio al grado superiore. Itera fino a raggiungere preloaded se la preload list è il tuo obiettivo.

Cos'è HSTS?

HSTS (HTTP Strict Transport Security) è un'intestazione di risposta HTTP standardizzata dall'RFC 6797 nel 2012. Quando un browser riceve questa intestazione su una connessione HTTPS valida, memorizza il dominio e rifiuta, per la durata definita, qualsiasi connessione in chiaro verso quel dominio. La conversione da http:// a https:// viene eseguita localmente dal browser, prima del minimo pacchetto di rete, eliminando così la finestra di intercettazione durante il primo redirect.

L'intestazione è composta da tre direttive:

max-age: durata in secondi durante la quale il browser applica HSTS. Valore raccomandato per la produzione stabile: 31536000 (1 anno). Per la preload list: minimo 31536000.
includeSubDomains: estende la protezione a tutti i sottodomini (www, api, mail, ecc.). Obbligatoria per la preload list.
preload: indica il consenso del proprietario all'invio del dominio alla preload list di Chrome. Senza questa direttiva, hstspreload.org rifiuta l'invio.

Esempio di intestazione completa:

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

Senza HSTS, un utente che digita captaindns.com nella barra degli indirizzi invia prima una richiesta HTTP in chiaro. Un attaccante sulla stessa rete Wi-Fi può intercettare quella richiesta e servire una versione contraffatta del sito (attacco SSL stripping). HSTS rende questo attacco impossibile dopo la prima visita legittima, e la preload list lo rende impossibile fin dalla prima visita per i domini precaricati nel browser.

I 5 gradi spiegati

CaptainDNS assegna un grado in base alle direttive rilevate e allo stato preload. Ecco la griglia di valutazione:

Grado	Criterio tecnico	Azione raccomandata
missing	Nessuna intestazione Strict-Transport-Security restituita	Attivare HSTS sul server, iniziare con max-age=300 e poi salire
weak	Intestazione presente ma max-age inferiore a 86400 (1 giorno)	Aumentare max-age, puntare ad almeno 604800 (1 settimana)
good	max-age maggiore o uguale a 86400, senza includeSubDomains o senza preload	Auditare i sottodomini e poi aggiungere includeSubDomains
preload-ready	max-age maggiore o uguale a 31536000, includeSubDomains e preload presenti, redirect HTTP verso HTTPS attivo	Inviare il dominio su hstspreload.org
preloaded	Dominio confermato nella preload list di Chrome	Sorvegliare la coerenza (ogni sottodominio deve restare accessibile in HTTPS)

Il grado preload-ready non significa che il dominio sia nella preload list: indica solo che soddisfa le condizioni tecniche per esservi inviato. L'invio vero e proprio avviene su hstspreload.org e l'inclusione in Chrome richiede generalmente dalle 6 alle 12 settimane.

Come correggere la tua configurazione HSTS

Ecco gli snippet pronti da incollare per le tre piattaforme più comuni. Tutti attivano un HSTS conforme ai requisiti della preload list.

Nginx

# /etc/nginx/sites-available/captaindns.com
server {
    listen 443 ssl http2;
    server_name captaindns.com;

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

La parola chiave always garantisce che l'intestazione venga inviata anche nelle risposte di errore (4xx, 5xx). Senza questa parola chiave, una pagina 404 non porterebbe l'intestazione HSTS.

Apache (mod_headers)

# /etc/apache2/sites-available/captaindns.com.conf
<VirtualHost *:443>
    ServerName captaindns.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

Attiva il modulo con a2enmod headers se non è già attivo, poi ricarica Apache.

Cloudflare Workers

addEventListener('fetch', event =&gt; {
    event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
    const response = await fetch(request);
    const newHeaders = new Headers(response.headers);
    newHeaders.set(
        'Strict-Transport-Security',
        'max-age=31536000; includeSubDomains; preload'
    );
    return new Response(response.body, {
        status: response.status,
        statusText: response.statusText,
        headers: newHeaders,
    });
}

Su Cloudflare puoi anche attivare HSTS dalla dashboard (SSL/TLS, Edge Certificates, HTTP Strict Transport Security) senza distribuire un Worker.

Dopo ogni modifica, rilancia il test HSTS per confermare la presa in carico lato CDN o reverse proxy.

Iscriversi alla preload list di HSTS

La preload list è un elenco di domini codificato in modo statico in Chrome (e ripreso da Firefox, Safari, Edge e Opera). Qualsiasi dominio presente nella lista viene trattato come HTTPS-only dai browser fin dalla prima visita, senza nemmeno bisogno di ricevere l'intestazione HSTS in anticipo.

Per inviare un dominio su hstspreload.org, deve soddisfare quattro condizioni:

max-age maggiore o uguale a 31536000 (1 anno).
Direttiva includeSubDomains presente nell'intestazione.
Direttiva preload presente nell'intestazione.
Redirect HTTP verso HTTPS attivo sul dominio principale e su tutti i sottodomini.

Anche il certificato deve essere valido (catena completa, non autofirmato, non scaduto). Una volta accettato l'invio, l'inclusione in Chrome richiede in media dalle 6 alle 12 settimane, il tempo necessario perché la modifica venga pubblicata in una nuova versione stabile del browser.

Avvertenza sull'irreversibilità. La rimozione di un dominio dalla preload list è tecnicamente possibile (modulo di rimozione su hstspreload.org), ma richiede diversi mesi e si applica solo alle versioni future di Chrome. Gli utenti su versioni più vecchie continueranno a forzare l'HTTPS per anni. Prima di inviare, verifica che ogni sottodominio di produzione, di staging e di amministrazione interna sia accessibile in HTTPS, e che non ci sia un piano di migrazione verso un altro nome a dominio nel breve termine.

Casi d'uso concreti

Incidente 1: grado weak dopo un audit ANSSI

Sintomo: un audit ANSSI segnala che captaindns.com invia effettivamente un'intestazione HSTS, ma che il valore di max-age (3600) è troppo basso per offrire una protezione reale.

Diagnosi: il test HSTS conferma la presenza dell'intestazione Strict-Transport-Security: max-age=3600. Nessuna direttiva includeSubDomains né preload. Il grado assegnato è weak.

Azione: modificare la configurazione Nginx per passare a max-age=31536000; includeSubDomains; preload, dopo aver validato che tutti i sottodomini (api, mail, status) rispondono in HTTPS. Rilanciare il test: il grado passa a preload-ready.

Incidente 2: sottodominio rotto dopo l'attivazione di includeSubDomains

Sintomo: dopo l'attivazione di includeSubDomains su captaindns.com, lo strumento interno metrics.captaindns.com diventa irraggiungibile per i team. Errore "ERR_SSL_PROTOCOL_ERROR" in Chrome.

Diagnosi: il sottodominio metrics dispone solo di un endpoint HTTP. La direttiva includeSubDomains, memorizzata dai browser dei team, forza ora l'HTTPS, ma nessun certificato viene servito su questo sottodominio.

Azione: distribuire d'urgenza un certificato Let's Encrypt su metrics, oppure rimuovere temporaneamente la direttiva includeSubDomains e svuotare la cache HSTS locale dei team (chrome://net-internals/#hsts) il tempo di rimettere il sottodominio in conformità.

Incidente 3: dominio preload-ready mai inviato

Sintomo: durante un audit di sicurezza interno, il test rivela che captaindns.com è preload-ready da più di un anno, ma non è nella preload list di Chrome. I nuovi visitatori restano vulnerabili al SSL stripping fin dalla prima visita.

Diagnosi: la configurazione del server è corretta (max-age=31536000, includeSubDomains, preload, redirect HTTP verso HTTPS). Lo stato preload restituito da Chrome è "Not in preload list".

Azione: inviare il dominio su hstspreload.org. Seguire la conferma e poi attendere dalle 6 alle 12 settimane per la propagazione nella versione stabile di Chrome. Documentare la decisione e la sua irreversibilità nel registro interno di sicurezza.

FAQ - Domande frequenti

D: Cos'è HSTS?

R: HSTS (HTTP Strict Transport Security) è un'intestazione HTTP di risposta definita dall'RFC 6797. Indica al browser di contattare il dominio solo in HTTPS per la durata indicata da max-age. Una volta memorizzata l'intestazione, il browser converte ogni richiesta http:// in https:// prima dell'invio, impedendo i downgrade e gli attacchi SSL stripping sulle reti non controllate.

D: Quale valore di max-age scegliere per HSTS?

R: Per una messa in produzione prudente, inizia con max-age=300 (5 minuti) per testare senza impegno. Una volta validata la catena HTTPS, sali progressivamente a 86400 (1 giorno) e poi 604800 (1 settimana). Per la preload list il valore minimo richiesto è 31536000 (1 anno), che è anche il valore raccomandato in produzione stabile. Un valore più alto non porta alcun guadagno aggiuntivo.

D: Il preload HSTS è reversibile?

R: Sì, ma in pratica molto lentamente. Puoi richiedere la rimozione tramite hstspreload.org, ma l'operazione richiede diversi mesi e si applica solo alle versioni future di Chrome. Gli utenti su versioni più vecchie continueranno a forzare l'HTTPS per anni. Prima di inviare un dominio, assicurati che tutte le risorse, inclusi i sottodomini interni, siano accessibili in HTTPS.

D: HSTS funziona senza HTTPS?

R: No. L'RFC 6797 richiede che l'intestazione Strict-Transport-Security venga ignorata quando viene ricevuta tramite HTTP. Solo le risposte servite su una connessione TLS valida possono attivare HSTS nel browser. Devi quindi prima distribuire un certificato valido (Let's Encrypt, ad esempio) e reindirizzare tutto il traffico HTTP verso HTTPS prima di inviare l'intestazione.

D: HSTS e redirect HTTPS, qual è la differenza?

R: Un redirect 301 da HTTP a HTTPS viene eseguito dal server dopo che la richiesta in chiaro ha lasciato il dispositivo. Un attaccante in posizione di man-in-the-middle può intercettare quella prima richiesta. HSTS risolve il problema: dopo la prima visita, il browser converte da solo http:// in https:// prima di qualsiasi invio in rete. Il redirect resta necessario per la prima visita e per i client che non hanno mai ricevuto l'intestazione.

D: Bisogna attivare includeSubDomains?

R: Sì, non appena tutti i sottodomini (www, api, mail, admin, intranet, ecc.) sono accessibili in HTTPS. La direttiva includeSubDomains estende la protezione HSTS all'intero dominio ed è obbligatoria per la preload list. Prima di attivarla, audita ogni sottodominio attivo: un sottodominio interno in HTTP (ad esempio uno strumento di monitoraggio) diventerà irraggiungibile una volta che i browser avranno memorizzato l'intestazione.

Strumenti complementari

Il test HSTS si combina con altri strumenti CaptainDNS per coprire la sicurezza HTTP, DNS e mail:

Strumento	Utilità
Analizzatore di header HTTP	Vista esaustiva dei security header (CSP, X-Frame-Options, Permissions-Policy) con un voto da A a F
Redirect Checker	Verificare la catena di redirect HTTP verso HTTPS, richiesta per la preload list
DNSSEC Check	Difesa in profondità lato DNS: completare la sicurezza HTTPS con la firma della zona
MTA-STS Record Check	Equivalente HSTS per SMTP: forzare TLS sui flussi di posta in entrata
Uptime Monitor	Monitoraggio continuo per rilevare una regressione HSTS appena si verifica
Page Crawl Checker	Audit on-page completo (HTML, header, comportamento) per validare una messa in produzione

Risorse utili

Guida completa HSTS e preload list di CaptainDNS (guida di riferimento per attivare Strict-Transport-Security passo dopo passo: direttive, configurazioni Nginx, Apache, Cloudflare, AWS, Caddy, invio alla preload list)
hstspreload.org (modulo ufficiale di invio alla preload list di Chrome)
MDN: Strict-Transport-Security (documentazione di riferimento sull'intestazione HSTS e le sue direttive)
RFC 6797 (specifica originale di HTTP Strict Transport Security)
OWASP HSTS Cheat Sheet (buone pratiche di distribuzione di HSTS)
content-security-policy.com (guida pratica su HSTS ed esempi di configurazione)

Test HSTS e verifica della preload list

Audita la tua intestazione Strict-Transport-Security e la preload list