Perché il browser del visitatore riapre il tuo sito in chiaro

Il browser del visitatore può riaprire il tuo sito in chiaro, anche se la pagina vive su HTTPS. La riga sulla risposta non cambia la risposta già arrivata: chiede al browser di ricordare l'host e, alle visite dopo, di usare solo il canale sicuro. Il nome della riga è Strict-Transport-Security. La sigla che si legge in giro è HSTS. Il 2 novembre 2026 ho letto RFC 6797, novembre 2012, Standards Track, e la pagina MDN su questo header, ultima modifica 11 settembre 2026. Non ho aperto l'elenco degli errata. Non ho misurato un browser.

Questa pagina non descrive i cookie del sito. Quella pagina è già pubblicata. Non la riscrivo. Il file in chiaro dentro una pagina HTTPS è un'altra pagina. Non la riscrivo. La riga che dice che cosa la pagina può caricare è un'altra pagina. Non l'ho aperta.

La prima visita in chiaro non è coperta

La sezione 5.1 dice che l'host si dichiara mandando la riga su un trasporto sicuro, per esempio TLS. Se il browser la riceve senza errori, considera l'host noto. La sezione 5.2 dice che la policy chiede di parlare con quell'host solo su trasporto sicuro, per un tempo, e che questo vale anche per ciò che il visitatore scrive nella barra, se l'host è già noto.

La sezione 14.6 dice che, se il visitatore scrive un indirizzo in chiaro, o segue un collegamento in chiaro, verso un host che il browser non ha ancora annotato, il primo scambio usa il canale non sicuro. La sezione rimanda a un altro testo, che non ho aperto. Non descrivo quei passi. MDN dice lo stesso limite con altre parole: la riga non ha effetto finché il browser non ha fatto almeno una connessione sicura e non ha ricevuto l'header. Se prima carica un indirizzo in chiaro, quella richiesta iniziale resta esposta. MDN aggiunge che il preload attenua il problema.

La sezione 12 del RFC è non normativa. Indica due vie, e non mette un terzo segno nel header: una policy che l'utente dichiara prima della visita, sezione 12.2, e una lista precaricata dal fornitore del browser, sezione 12.3. MDN tratta preload come un segno della riga. Non ho unito le due pagine.

Che cosa la riga deve contenere

La sezione 6.1 dà il nome del campo, Strict-Transport-Security. I segni si separano con un punto e virgola. L'ordine non conta. Ogni segno compare una sola volta. I nomi dei segni non distinguono le maiuscole. Se la riga non rispetta la grammatica, il browser la ignora per intero. Se c'è un segno che questo documento non definisce, il browser ignora quel segno e, se il resto è valido, applica i segni che conosce. I due segni definiti qui sono max-age e includeSubDomains. Altri segni possono arrivare da altre specifiche. Un browser che implementa solo questo RFC ignora i segni che non conosce.

La sezione 6.1.1 dice che max-age è obbligatorio. È il numero di secondi, dopo la ricezione, durante i quali l'host resta annotato. Il valore può stare tra virgolette doppie. Zero dice di smettere di considerare l'host noto, compreso includeSubDomains se c'era. La sezione 6.1.2 dice che includeSubDomains è facoltativo e non ha un valore. Se c'è, la policy vale anche per i sottodomini del nome.

Gli esempi della sezione 6.2: max-age=31536000 è circa un anno e vale solo per il dominio che manda la riga. max-age=15768000 insieme a includeSubDomains è circa sei mesi e vale anche per i sottodomini. max-age=0 cancella la policy. La stessa sezione dice che, con zero, il segno includeSubDomains nella stessa riga è ignorato.

La sezione 7.1 dice che, su una richiesta arrivata su trasporto sicuro, l'host dovrebbe includere la riga, e se la include deve includerne una sola. La sezione 8.1 dice il rovescio: se nella risposta ci sono due campi, il browser elabora solo il primo. Nel testo di MDN che ho letto non c'è la frase sui due campi.

Prima della sezione 7.1 il RFC dice che l'host non deve includere la riga nelle risposte portate su trasporto non sicuro. La sezione 8.1 dice che, se la risposta arriva così, il browser ignora la riga. MDN dice la stessa cosa e aggiunge un motivo: evitare che un intermediario la faccia scadere prima, o la aggiunga per un host che non parla in sicuro. La sezione 14.3 spiega lo stesso limite. Annotare l'host, o aggiornare il tempo, avviene solo se la riga arriva su un trasporto sicuro senza errori né avvisi. Altrimenti un intermediario potrebbe far annotare un host che non offre il servizio in sicuro, oppure azzerare il tempo. Non descrivo quei passi.

La sezione 7.2 dice che, se l'host riceve una richiesta su trasporto non sicuro, dovrebbe rispondere con un redirect permanente. Nomina come esempio lo status 301, con un indirizzo il cui schema è https. È un dovrebbe, non un deve. La nota dà due motivi: i rischi di quel redirect, e i siti che non si comportano bene se vengono reindirizzati. Non ho aperto la guida che la nota cita, né la sezione di HTTP che definisce il 301. MDN dice che quel redirect non deve contenere la riga, perché la richiesta era in chiaro, e che la riga va sulla risposta successiva, quella in sicuro, così le visite dopo non dipendono dal redirect. Non ho unito il dovrebbe del RFC e il racconto di MDN.

Come il browser annota l'host

La sezione 8.1: se la risposta è su trasporto sicuro, la riga è conforme, e non ci sono errori o avvisi del trasporto, il browser annota l'host se non lo conosce, oppure aggiorna il tempo e includeSubDomains se sono diversi da quelli in memoria. Il tempo è relativo al momento della ricezione. Se max-age è zero, cancella la policy di quell'host, oppure non lo annota se non lo conosceva.

La sezione 8.1.1: se l'host della richiesta è un indirizzo IP, nelle forme che il RFC chiama IP-literal e IPv4address dentro RFC 3986, il browser non lo annota. Non ho aperto RFC 3986. MDN dice che un indirizzo IP non può essere un host di questo meccanismo. Non ho unito le due formule.

Se il nome non coincide già con un host noto, il browser annota il nome, la scadenza e se includeSubDomains è affermato. Non modifica la scadenza né quel segno di un superdominio già in memoria. La sezione 5.3 tiene le policy separate: solo l'host che ha emesso la sua policy può aggiornarla o farla cancellare. MDN dice che max-age=0 sul dominio non cancella le policy separate dei sottodomini. Il paragrafo dello zero, nel RFC, non lo scrive in quella frase. Lo tengo come frase di MDN.

Un host è scaduto se la data in memoria è nel passato. Il browser deve togliere dalla memoria tutti gli host scaduti, se ce n'è uno. La sezione 8.6 dice che, se le risposte successive sul canale sicuro non portano più la riga, l'host resta noto fino alla scadenza. Il RFC nota che, per una lista preconfigurata, la scadenza può non arrivare mai. MDN dice la stessa permanenza, e che per spegnere la policy serve max-age=0 ricevuto su una richiesta sicura. Non si spegne da una risposta in chiaro. Questo coincide con l'obbligo di ignorare la riga in chiaro.

La sezione 8.5 dice che il browser non deve obbedire a un elemento della pagina che ripete il nome dell'header come attributo di equivalenza. Non ho aperto la raccomandazione HTML che il RFC cita. La pagina MDN che ho letto non ne parla.

La visita dopo

La sezione 8.3: quando il browser sta per caricare un indirizzo il cui schema è http, anche se sta seguendo un redirect, controlla se il nome è un host noto. Se il nome manca, non c'è corrispondenza. Se il nome è un indirizzo IP, non c'è corrispondenza. Altrimenti confronta, sezione 8.2, etichetta per etichetta, da destra verso sinistra, senza distinzione di maiuscole in ASCII.

I modi sono due. Corrispondenza congruente: il nome è lo stesso. Corrispondenza di superdominio: la parte destra coincide con un host noto, e di superdomini può essercene più d'uno. L'esempio del RFC usa il nome example.com con etichette a sinistra. Poi il punto 5 della sezione 8.3: se c'è un superdominio con includeSubDomains, oppure se un tale superdominio non c'è ma c'è una corrispondenza congruente, con o senza quel segno, allora prima di caricare il browser sostituisce lo schema con https. Se la porta scritta è 80, diventa 443. Se la porta scritta è un altro numero, resta. Se la porta non è scritta, il browser non ne aggiunge una. La nota dice che così la policy vale per HTTP su qualunque porta TCP di quell'host. Aggiunge che, se la porta è scritta, è facile che su quella porta risponda un server non sicuro e che la richiesta sicura fallisca. Non ho misurato una porta.

MDN descrive le stesse sostituzioni di schema e di porta, e dice che il confronto del nome non distingue le maiuscole. Non descrive il confronto etichetta per etichetta. Dice anche che la riga non cambia la risposta corrente, solo le richieste future. Il RFC mette la riscrittura nel momento in cui il browser prepara il caricamento. Non ho unito le due frasi.

La sezione 8.4: verso un host già noto, qualunque errore o avviso del trasporto sicuro chiude la connessione. Il RFC nomina i controlli sul certificato, le liste di revoca, il protocollo di stato del certificato e il controllo dell'identità. Non ho aperto quei documenti. La sezione 12.1, non normativa, dice che non va offerto un dialogo per proseguire. MDN dice che il browser non lascia aggirare un errore di certificato non valido. Non ho misurato un browser e non ho unito la norma e il consiglio.

I sottodomini, e il segno che il RFC non definisce

Le sezioni 5.2 e 5.4: se un superdominio noto ha includeSubDomains, la policy vale per l'host figlio. Se no, vale solo se l'host stesso è noto. La sezione 11.4 è non normativa e mette due casi. Servizi in chiaro su altre porte o su sottodomini, per esempio lo stato dei certificati: con il segno, quei recuperi in chiaro falliscono. Applicazioni diverse sui sottodomini, aperte senza passare dal nome padre: se la riga sta solo sul padre, quei browser non la vedono. Il consiglio, sezione 11.4.2, è mandare la riga su ogni nome che è un ingresso, anche se il segno dei sottodomini c'è. MDN dice la stessa cosa con un altro nome di scuola: il segno copre i nomi sotto, non il padre e non un fratello, e ogni nome sotto dovrebbe mandare la propria riga perché il browser può arrivare lì prima. Non ho unito gli esempi.

La sezione 14.4 dice che, senza il segno, la policy non protegge i cookie di dominio marcati Secure su un sottodominio che il browser non ha ancora annotato. Non descrivo quei passi. La pagina sui cookie non è stata riscritta. La sezione 14.5 dice che un host offerto solo in chiaro, una volta annotato, diventa irraggiungibile, perché il browser userà solo il trasporto sicuro. Lo stesso può accadere a un sottodominio che non ha il trasporto sicuro, se il padre ha il segno. Non descrivo i modi in cui qualcun altro può far annotare la policy. La sezione 12.5, non normativa, parla di una cancellazione per singolo host, e dice di farla con cautela.

Il RFC non definisce un segno di nome preload. La sezione 12.3, non normativa, descrive una lista precaricata: i fornitori del browser configurano la policy prima della prima visita, come i certificati delle autorità già presenti. Serve contro il limite della sezione 14.6. MDN elenca preload come segno facoltativo. Dice che, per usarlo, max-age deve essere almeno 31536000, un anno, e che includeSubDomains deve esserci. Dice che il servizio è tenuto da Google, che tutti i browser usano quella lista, e che la lista non fa parte della specifica e non va trattata come ufficiale. Attribuisce a un'altra pagina, che non ho aperto, un esempio di 63072000 secondi, circa due anni. Nel RFC, 31536000 è solo l'esempio di un anno, sezione 6.2, non un minimo. La sezione 6.1 dice che un segno non riconosciuto si ignora e che i segni riconosciuti si applicano lo stesso. Non ho aperto la lista, né la pagina di Chromium, né quel sito. Non ho misurato un browser. Non ho unito le due pagine.

La sezione 11.2, non normativa, distingue due modi. Si può mandare sempre lo stesso max-age, e ogni ricezione aggiorna il momento in cui il browser deve dimenticare l'host. L'esempio è 7776000 secondi, 90 giorni. Oppure si possono mandare i secondi che restano fino a una data fissa. MDN dice che un valore fisso, ricevuto di nuovo, spinge la scadenza più avanti. È la stessa idea del primo modo. Non ho unito quella frase con il secondo modo. La sezione 11.3, anch'essa non normativa, dice che un certificato firmato da un'autorità che il browser non ha già fa fallire la connessione, se le quattro condizioni di quella sezione sono vere. Non ho aperto i documenti che cita. La nota sconsiglia di far installare all'utente un'autorità privata. Non do i passi.

Esempio ipotetico

bottega.example e scheda.bottega.example sono nomi di scuola. Non ho letto una risposta di quei nomi. Non ho misurato un browser.

Una persona apre bottega.example con lo schema http, la prima volta. Il browser non ha l'host. La sezione 14.6 dice che quel primo scambio è in chiaro. Se la bottega risponde come nella sezione 7.2, manda un redirect permanente verso lo schema https e non mette la riga su quella risposta. Sulla risposta sicura, senza errori, la riga con max-age e, se c'è, includeSubDomains fa annotare l'host. Una visita dopo che parte da un indirizzo in chiaro viene riscritta prima del caricamento, sezione 8.3. Se la porta scritta è 80 diventa 443. Un'altra porta resta.

scheda.bottega.example è coperta solo se la policy di bottega.example ha includeSubDomains, oppure se scheda.bottega.example ha una propria policy. MDN direbbe la stessa copertura e aggiungerebbe che il nome sotto dovrebbe mandare la propria riga. Il RFC, sezione 11.4.2, dice la stessa cosa per gli ingressi. Non ho unito le pagine.

Se la riga contenesse anche il segno preload, RFC 6797 non gli dà un significato: un browser che implementa solo quel testo lo ignora e applica max-age e includeSubDomains. MDN lo tratta come la richiesta di entrare nella lista, con un minimo di un anno e il segno dei sottodomini, e dice che la lista non è la specifica. Non ho aperto la lista. Se max-age fosse zero sulla risposta sicura, la policy di bottega.example si cancella. MDN aggiunge che le policy separate dei sottodomini restano. Il paragrafo dello zero nel RFC non lo scrive in quella frase.

Che cosa questa pagina lascia stare

Non ho aperto gli errata di RFC 6797, né RFC 3986, né RFC 2616, né la guida citata sul redirect, né il testo a cui rimanda la sezione 14.6, né la raccomandazione HTML, né i documenti sui certificati e sulle revoche, né la lista preload, né la pagina di Chromium, né il sito a cui MDN attribuisce l'esempio di due anni. Non ho misurato un browser. Non ho riscritto la pagina sui cookie né quella sul file in chiaro. Non ho aperto la pagina sulla riga che limita che cosa la pagina può caricare. La copertina di questa pagina non è stata cambiata.

Fonti lette il 2 novembre 2026: RFC 6797, novembre 2012, https://www.rfc-editor.org/rfc/rfc6797 e la pagina MDN su Strict-Transport-Security, ultima modifica 11 settembre 2026, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security.