Defaults.Exposed › Correzioni › HSTS (Strict-Transport-Security)

Come correggere HSTS (Strict-Transport-Security)

L'HSTS è un'istruzione di una riga che il tuo sito dà a ogni browser: «torna sempre da me sulla connessione sicura e cifrata — mai su quella insicura». Senza, il tuo lucchetto può essere strappato via in silenzio su una WiFi condivisa, e la primissima visita al tuo sito è esposta.

In sintesi per la tua attività: Avere HTTPS (il lucchetto) non è la stessa cosa di imporlo. Senza HSTS, un attaccante sulla stessa WiFi del tuo cliente può declassare in silenzio la connessione a HTTP semplice e non cifrato — catturando accessi, dati delle carte e dati dei moduli mentre il cliente non vede nulla di anomalo. Il tuo certificato SSL, che magari stai pagando, viene aggirato. La correzione è gratuita e richiede circa 15 minuti a chi gestisce il tuo sito.

Cosa può costarti

• I clienti su WiFi di bar, hotel, aeroporto o conferenza possono vedersi declassare in silenzio la connessione al tuo sito e i loro dati letti — senza alcun avviso sullo schermo.
• Hai pagato per l'HTTPS e hai il lucchetto, ma senza HSTS gli attaccanti possono semplicemente aggirarlo; il certificato dà un falso senso di sicurezza.
• La primissima visita al tuo sito (prima di qualsiasi reindirizzamento a HTTPS) è il punto debole che gli attaccanti prendono di mira — l'HSTS è ciò che lo chiude per ogni visita di ritorno.
• Un questionario di sicurezza, un modulo di cyber-assicurazione o la checklist di un acquirente aziendale segnala «niente HSTS» e blocca l'affare finché non è sistemato.
• Imposta il valore sbagliato (troppo breve) e ottieni il peggio dei due mondi: sembra configurato ma offre quasi nessuna protezione reale.

Perché è importante. L'HTTPS protegge una connessione una volta che è cifrata — ma non forza i browser a usarla. Gli attaccanti sfruttano quella lacuna con lo «SSL stripping»: su qualsiasi rete condivisa tengono in silenzio il visitatore su HTTP insicuro, leggendo tutto. L'HSTS dice al browser di rifiutare del tutto l'HTTP semplice per il tuo dominio, per molto tempo, così la lacuna si chiude dopo la prima visita. È una singola intestazione di risposta, gratuita da aggiungere, e nella nostra valutazione vale punti reali perché un valore mancante o troppo breve lascia esposto ogni visitatore su WiFi pubblica.

Cos’è, in parole semplici

Quasi certamente hai HTTPS — il piccolo lucchetto nella barra del browser. Bene. Ma ecco la parte che quasi nessuno ti dice: avere HTTPS non è la stessa cosa di forzarlo.

L’HTTPS rende una connessione cifrata una volta che il browser decide di usarla. L’HSTS — abbreviazione di HTTP Strict Transport Security — è l’istruzione che fa sì che il browser la usi sempre. È una singola riga invisibile che il tuo sito invia a ogni visitatore e che dice, in sostanza:

«D’ora in poi, per il mio dominio, parlami solo sulla connessione sicura. Mai su quella insicura. Non provarci nemmeno.»

Il browser se lo ricorda e lo rispetta per tutto il tempo che gli dici — tipicamente un anno. Dopo la prima visita sicura di un visitatore, il suo browser si rifiuterà semplicemente di caricare il tuo sito su HTTP semplice e non cifrato, anche se qualcosa prova a forzarlo.

Senza HSTS, quella regola «usa sempre la versione sicura» non esiste — e gli attaccanti sanno esattamente come sfruttare la lacuna.

Quanto può costarti

Questi sono scenari realistici e quotidiani. Non nominiamo mai un’azienda reale; sono esempi di come la lacuna viene sfruttata.

1. Il checkout al bar. Un cliente apre il tuo negozio su WiFi di un bar e va a pagare. Un attaccante sulla stessa rete esegue uno strumento gratuito e ben noto che tiene il cliente su HTTP semplice invece che HTTPS. Il cliente vede quello che sembra il tuo sito normale — nessun avviso, nessun lucchetto rotto nel punto in cui darebbe un’occhiata — e digita i dati della carta. L’attaccante legge ogni battitura. Il tuo certificato SSL non ha fatto nulla, perché alla connessione non è mai stato permesso di diventare sicura, prima di tutto.

2. Il dipendente in viaggio. Un membro dello staff accede al tuo pannello di amministrazione o alla webmail da un hotel o un aeroporto. Lo stesso trucco di declassamento cattura il suo nome utente e la sua password. Ora l’attaccante ha una via d’accesso alla tua azienda — non perché la tua policy sulle password fosse debole, ma perché la pagina di accesso era raggiungibile su HTTP insicuro.

3. L’affare che si blocca. Un cliente più grande ti invia il suo questionario di sicurezza standard prima di firmare. Una riga chiede: «Il vostro sito impone l’HTTPS tramite HSTS?». Il tuo referente IT deve rispondere «no», e il processo di acquisto si ferma mentre corri a sistemare un’impostazione gratuita di 15 minuti che ora sembra una bandiera rossa davanti a un acquirente.

4. Il controllo di cyber-assicurazione o conformità. La scansione di un assicuratore, o un revisore che esamina la tua postura di protezione dei dati, segnala l’intestazione mancante. La cifratura dei dati personali è un’aspettativa esplicita secondo le regole sulla protezione dei dati (Articolo 32 del GDPR), e «abbiamo un certificato ma non lo imponiamo» è una posizione debole in cui trovarsi.

5. Il falso senso di sicurezza. Stai pagando per l’SSL, il lucchetto compare, e tutti danno per scontato che il sito sia sicuro. Per lo più lo è — finché un cliente non è su una rete condivisa, che è esattamente quando è più vulnerabile e meno propenso a notare qualcosa di anomalo.

Il filo conduttore: il costo non è astratto. È la carta o l’accesso di un cliente reale, catturati nel momento peggiore possibile, senza che scatti alcun allarme.

Cos’è davvero

Quando un browser chiede una pagina al tuo sito, il tuo server rimanda indietro la pagina più alcune «intestazioni» invisibili — istruzioni extra che il browser legge ma che il visitatore non vede mai. L’HSTS è una di quelle intestazioni:

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

Contano tre parti:

• max-age — per quanto tempo (in secondi) il browser dovrebbe ricordarsi di forzare l’HTTPS. 31536000 è un anno. È il cuore della questione: troppo breve e aiuta a malapena.
• includeSubDomains — estende la regola a ogni sottodominio (negozio., app., mail. e così via), non solo al tuo indirizzo principale.
• preload — iscrive il tuo dominio a una lista principale integrata nei browser, così la protezione si applica persino alla primissima richiesta di un visitatore, prima che abbia mai visto il tuo sito.

Perché «la prima visita» conta

L’HSTS ha un limite intrinseco: un browser obbedisce alla regola solo dopo aver visto l’intestazione almeno una volta. Quindi la primissima connessione di un visitatore nuovo è ancora una minuscola finestra di esposizione. Due cose la restringono: un reindirizzamento da HTTP a HTTPS (che lo porta sulla versione sicura in fretta) e il preload (che rimuove del tutto la finestra). È per questo che una configurazione completa abbina l’HSTS a un reindirizzamento adeguato.

Com’è fatto un «buono» — e come viene valutato

Il nostro controllo legge la tua intestazione in tempo reale e valuta il max-age:

Quindi un’intestazione che esiste ma è impostata su pochi minuti viene trattata come un fallimento — sembra configurata ma non fa il suo lavoro. Punta a un anno. Il controllo nota anche se includeSubDomains e preload sono presenti.

Come sistemarlo (gratis, ~15 minuti)

Passa questa sezione a chi gestisce il tuo sito — la tua persona IT, il tuo sviluppatore web, o il supporto del tuo hosting. La correzione è gratuita. È una singola intestazione, o un interruttore nella tua piattaforma di hosting. Non c’è nulla da comprare.

Una regola importante di ordine prima di tutto: l’HSTS è appiccicoso — una volta abilitato, i browser rifiuteranno l’HTTP semplice per il tuo dominio per l’intero max-age. Quindi conferma che l’HTTPS funzioni correttamente sul tuo sito principale e su ogni sottodominio prima di attivarlo su larga scala. La via sicura è: testa con un valore breve → conferma che nulla si rompa → alza a un anno.

Passo 1 — Assicurati che l’HTTPS funzioni già ovunque

Visita il tuo sito e i sottodomini chiave su https:// e conferma che si carichino in modo pulito con un certificato valido. Conferma anche che le richieste http:// semplici reindirizzino a https://. (Se non lo fanno, sistema prima il reindirizzamento da HTTP a HTTPS — l’HSTS presuppone che sia a posto.)

Passo 2 — Aggiungi l’intestazione (scegli la tua piattaforma)

Cloudflare (o CDN simile): È il più facile. Vai su SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) e abilitalo. Imposta il Max-Age su 6 mesi o 12 mesi, e abilita «Apply HSTS policy to subdomains» una volta che sei sicuro che tutti i sottodomini siano su HTTPS.

Nginx: aggiungi dentro il tuo blocco server HTTPS:

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

Apache: assicurati che mod_headers sia abilitato, poi aggiungi al tuo virtual host HTTPS:

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

Microsoft IIS: aggiungi a web.config dentro <customHeaders>:

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

Nota su Google Workspace / Microsoft 365: questi alimentano la tua email, non l’hosting del tuo sito — l’HSTS si imposta ovunque viva davvero il tuo sito pubblico (il tuo CDN, server web o creatore di siti), non nell’admin di Workspace/365. Se il tuo sito è su un creatore come Squarespace, Wix o Shopify, l’HSTS è di solito gestito per te; controlla le loro impostazioni SSL/sicurezza se il nostro controllo lo segnala.

Passo 3 — Testa in piccolo, poi conferma

Parti con max-age=300 (5 minuti). Conferma che il sito si carichi ancora perfettamente ovunque. Poi alzalo a max-age=31536000 (un anno). Quella è l’impostazione da punteggio pieno.

Passo 4 (opzionale, riferimento d’eccellenza) — preload

Una volta che sei sicuro e hai fatto girare per un po’ un’intestazione di un anno con includeSubDomains, puoi inviare il tuo dominio su hstspreload.org per essere incorporato nei browser. Questo chiude del tutto la finestra della prima visita. Trattalo come un impegno deliberato — rimuovere un dominio dalla lista è lento.

Errori comuni

• Impostare max-age troppo breve. Un valore di pochi minuti o ore sembra configurato ma offre quasi nessuna protezione — e il nostro controllo tratta qualsiasi cosa sotto un giorno come un fallimento. Usa un anno.
• Attivare includeSubDomains prima che i sottodomini siano pronti per HTTPS. Se un sottodominio non è del tutto su HTTPS, la regola appiccicosa può renderlo irraggiungibile per i visitatori. Porta prima ogni sottodominio su HTTPS.
• Aggiungere l’HSTS ma non avere alcun reindirizzamento da HTTP a HTTPS. L’HSTS presuppone che i visitatori raggiungano la versione sicura; senza il reindirizzamento, la prima visita è inutilmente esposta. Sistema entrambi insieme.
• Saltare dritti al preload per «essere scrupolosi». Il preload è difficile da annullare. Guadagnatelo gradualmente dopo un’intestazione di un anno stabile — non avere fretta.
• Dare per scontato che il lucchetto significhi essere coperti. Il lucchetto e l’HSTS sono cose diverse. Puoi avere un certificato perfetto e fallire comunque questo controllo.

FAQ