Come configurare HSTS senza tagliarsi fuori

HSTS è semplice finché non lo è più

HTTP Strict Transport Security, di solito abbreviato in HSTS, dice ai browser: “per questo sito, usa sempre HTTPS.” Una volta che un browser riceve l'header tramite una connessione HTTPS valida, ricorda la regola per la durata specificata.

È utile. Previene gli attacchi di downgrade del protocollo, riduce le richieste insicure accidentali ed evita il momento scomodo in cui un utente digita example.com e passa brevemente da HTTP in chiaro prima di essere reindirizzato.

È anche persistente. Se pubblichi una policy HSTS errata, i browser possono continuare ad applicarla molto dopo che hai rimosso l'header dal server. È così che i team si tagliano fuori: non esattamente dal proprio pannello di amministrazione, ma dai browser degli utenti, dai sottodomini, dagli ambienti di staging, dagli endpoint legacy e dai servizi dimenticati che non sono pronti per HTTPS obbligatorio.

L'obiettivo non è evitare HSTS. L'obiettivo è distribuirlo come una migrazione, non come un interruttore.

Cosa fa davvero l'header HSTS

Un tipico header HSTS si presenta così:

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

Ha tre parti importanti:

• max-age: per quanto tempo, in secondi, il browser deve imporre HTTPS per questo host.
• includeSubDomains: se la regola si applica anche a ogni sottodominio.
• preload: un segnale che vuoi includere il dominio nelle liste di preload dei browser.

Il browser considera attendibile questo header solo quando lo riceve tramite HTTPS valido. Se il certificato non è valido, è scaduto o non corrisponde, il browser non dovrebbe accettare una nuova policy HSTS da quella risposta.

Una volta memorizzata la policy, i tentativi futuri di visitare http://example.com vengono aggiornati dal browser a https://example.com prima che la richiesta venga inviata. Questo è il vantaggio per la privacy: la richiesta insicura non lascia mai il dispositivo.

Gli scenari di lockout da evitare

La maggior parte dei problemi HSTS non è causata dal sito web principale. Si verifica ai margini.

1. Un sottodominio dimenticato non è pronto per HTTPS

includeSubDomains sembra ordinato, ma è assoluto. Se lo imposti su example.com, si applica a:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• qualsiasi altra cosa sotto quel dominio

Se uno di questi host non può servire HTTPS valido, gli utenti con la policy HSTS in cache non potranno raggiungerlo tramite HTTP.

2. Un certificato scade

Senza HSTS, a volte gli utenti proseguono oltre gli avvisi sui certificati. Non è una buona pratica di sicurezza, ma succede.

Con HSTS, i browser moderni non consentono un bypass semplice degli errori di certificato per quell'host. Questo è il punto. Significa anche che il rinnovo dei certificati deve essere noioso, monitorato e testato.

3. Strumenti di staging o interni vivono sotto il dominio di produzione

Mettere strumenti interni sotto *.example.com può diventare doloroso quando il dominio padre usa includeSubDomains. Se questi strumenti usano certificati autofirmati, autorità di certificazione private, vecchie configurazioni TLS o nessun HTTPS, HSTS renderà visibile la scorciatoia.

Questo è uno dei motivi per cui molti team mantengono sistemi interni e sperimentali sotto un dominio separato con una propria policy di sicurezza.

4. Il preload viene trattato come una checkbox di routine

Il preload HSTS non è solo un'altra direttiva. Significa che il tuo dominio può essere distribuito all'interno dei browser come solo HTTPS prima che qualsiasi utente abbia visitato il sito.

Questo chiude il divario della “prima visita”, ma è molto più difficile da annullare. La rimozione dalle liste di preload può richiedere settimane o mesi per raggiungere gli utenti, a seconda dei cicli di rilascio dei browser. Il preload è adatto a domini stabili e maturi. Non è adatto a un sito che sta ancora scoprendo l'inventario dei propri sottodomini.

Un piano di rollout sicuro

Step 1: Verifica ogni hostname che controlli

Prima di impostare includeSubDomains, elenca ogni hostname sotto il dominio. I record DNS sono un punto di partenza, ma non raccontano tutta la storia. Controlla configurazioni CDN, dashboard di hosting, hostname legati all'email, vecchi strumenti marketing, bucket di storage e documentazione interna.

Per ogni hostname, rispondi:

• Serve HTTP, HTTPS o entrambi?
• Il certificato HTTPS è valido e rinnovato automaticamente?
• Reindirizza HTTP a HTTPS in modo pulito?
• È pensato per essere pubblico?
• Serve ancora?

Se il tuo team ha già abitudini di debug degli header in produzione, questo si integra naturalmente accanto ai controlli su redirect e header. Abbiamo trattato quel flusso di lavoro in un piccolo toolkit per fare debug di redirect e header HTTP in produzione.

Step 2: Sistema HTTPS prima di aggiungere HSTS

HSTS non rende sicura una configurazione HTTPS rotta. Rende solo HTTPS obbligatorio.

Prima di abilitarlo, verifica:

• I certificati TLS coprono gli hostname corretti.
• I certificati si rinnovano automaticamente.
• HTTP reindirizza a HTTPS con un solo passaggio pulito, dove possibile.
• I redirect dell'host canonico sono coerenti, per esempio da non-www a www, o il contrario.
• Gli asset dell'applicazione non dipendono da URL http:// insicuri.

Il mixed content è meno comune di un tempo, ma compare ancora in vecchi temi CMS, snippet di analytics, media incorporati e percorsi immagine hard-coded.

Step 3: Inizia con un max-age molto breve

Non iniziare con un anno. Inizia con cinque minuti:

Strict-Transport-Security: max-age=300

Distribuiscilo solo sull'hostname che stai testando, di solito il sito web di produzione canonico. Per ora ometti includeSubDomains.

Poi testa nei browser reali e con richieste da riga di comando:

curl -I https://example.com

Dovresti vedere esattamente un header Strict-Transport-Security. Header HSTS duplicati da un application server e da una CDN sono una fonte comune di confusione. I browser in genere applicano la policy effettiva, ma le persone che fanno debug di un incidente non hanno bisogno di ambiguità.

Step 4: Aumenta gradualmente

Se nulla si rompe, aumenta la durata per fasi:

Strict-Transport-Security: max-age=86400

Poi:

Strict-Transport-Security: max-age=604800

Poi magari:

Strict-Transport-Security: max-age=2592000

Una pianificazione pratica è:

• 5 minuti
• 1 giorno
• 1 settimana
• 1 mese
• 6 mesi o 1 anno

Non c'è alcun premio per la fretta. Il punto del rollout graduale è dare a monitoraggio, inbox del supporto e casi limite il tempo di dirti cosa la checklist ha mancato.

Step 5: Aggiungi includeSubDomains solo dopo una verifica reale

Una volta che ogni sottodominio pubblico è pronto per HTTPS, puoi considerare:

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

Questo è il momento di essere prudenti. Se un servizio legacy ha ancora bisogno di HTTP, non aggiungere includeSubDomains al dominio padre. Migra quel servizio, spostalo su un altro dominio oppure accetta che la tua policy HSTS debba restare più limitata per ora.

Gli header di sicurezza dovrebbero riflettere la realtà. Non dovrebbero essere usati come poster motivazionali per un'infrastruttura che speri di avere in seguito.

Step 6: Tratta il preload come un progetto separato

Considera il preload solo quando tutte le condizioni seguenti sono vere:

• Il dominio e tutti i sottodomini supportano HTTPS valido.
• HTTP reindirizza a HTTPS.
• L'header HSTS usa max-age di almeno 31536000 secondi.
• L'header include includeSubDomains.
• L'header include preload.
• Sei sicuro che non ti servirà HTTP in chiaro da nessuna parte sotto il dominio.

Un header pronto per il preload si presenta così:

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

L'invio alla lista di preload è un impegno a lungo termine. Se il sito è un microsito di campagna, un dominio di prodotto temporaneo o un dominio con confini di proprietà poco chiari, saltalo.

Esempi di configurazione

Nginx

Usa always in modo che l'header venga inviato anche nelle risposte di errore:

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

Dopo che il rollout è stabile:

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

Apache

Con mod_headers abilitato:

Header always set Strict-Transport-Security "max-age=300"

In seguito:

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

CDN o piattaforma edge

Se la tua CDN imposta gli header di risposta, preferisci gestire HSTS in un unico punto. Non impostare una policy all'origine e un'altra all'edge a meno che tu non abbia una ragione molto chiara.

Controlla anche se la CDN applica gli header a redirect, errori in cache e pagine di errore personalizzate. Un sito di produzione non è solo la sua risposta 200 OK.

Come annullare HSTS in sicurezza

Se devi disabilitare HSTS, invia:

Strict-Transport-Security: max-age=0

Ma c'è un problema: il browser deve riuscire a raggiungere il sito tramite HTTPS valido per ricevere quell'header. Se HTTPS stesso è rotto, gli utenti con una policy HSTS in cache non possono recuperare l'istruzione che la cancellerebbe.

Quindi l'ordine di recupero abituale è:

1. Ripristina HTTPS valido.
2. Servi Strict-Transport-Security: max-age=0.
3. Tienilo in posizione abbastanza a lungo perché gli utenti di ritorno lo ricevano.
4. Rimuovi o sostituisci l'header dopo che l'incidente è risolto.

Se il dominio è in preload, servire max-age=0 non basta per i nuovi profili browser. Devi anche richiedere la rimozione dalla lista di preload e attendere che la modifica venga distribuita tramite gli aggiornamenti dei browser.

Checklist di test prima della pubblicazione

Usa questa checklist prima di aumentare max-age o aggiungere includeSubDomains:

• L'URL HTTPS canonico restituisce un certificato valido.
• HTTP reindirizza a HTTPS.
• C'è un solo header HSTS.
• L'header appare su redirect e risposte di errore dove appropriato.
• Tutti i sottodomini pubblici hanno HTTPS valido.
• Il rinnovo dei certificati è monitorato.
• Nessun sistema interno critico dipende da HTTP sotto lo stesso dominio padre.
• Il preload è stato discusso esplicitamente, non aggiunto per abitudine.

Lighthouse può anche segnalare header di sicurezza mancanti o deboli in alcuni contesti, ma non dovrebbe essere il tuo unico metodo di verifica. Se lo usi come parte di una revisione più ampia, leggi i risultati come segnali invece che come verdetti; la stessa mentalità si applica quando leggi un report Lighthouse senza farti prendere dal panico.

<!-- tool-cta:start -->

💡 Prova questo: Prima e dopo ogni modifica HSTS, ispeziona la risposta Strict-Transport-Security con Get Headers per confermare che max-age, includeSubDomains e preload siano quelli che ti aspetti.

<!-- tool-cta:end -->

Il caso privacy per HSTS

HSTS viene spesso presentato come un header di sicurezza, e lo è. Ha anche un beneficio per la privacy: riduce la possibilità che la prima richiesta di un utente trapeli su HTTP in chiaro in una rete non attendibile.

Questo conta sul Wi-Fi degli aeroporti, sulle reti degli hotel, sulle reti guest aziendali e ovunque il traffico di un utente possa essere osservato o modificato. Una richiesta HTTP in chiaro può esporre hostname, path, cookie senza flag Secure e altri dettagli della richiesta. HTTPS non è magia, ma imporlo in modo coerente rimuove un'intera classe di perdite evitabili.

Le migliori distribuzioni HSTS sono poco interessanti. Vengono rilasciate lentamente, supportate da certificati affidabili e sono abbastanza noiose da non farsi notare da nessuno. È esattamente ciò che vuoi da un header il cui modo di fallire può essere drammatico.