HSTS: l'header che il plugin «forza HTTPS» non sostituisce

Un plugin che «forza HTTPS» fa un redirect 301. L’HSTS è un header. Il primo è una risposta, intercettabile, sulla prima richiesta in chiaro. Il secondo dice al browser: per questo dominio, per i prossimi N secondi, non usare HTTP. Non sono lo stesso mestiere. Confonderli è il modo per credere di aver chiuso il downgrade TLS quando si è solo acceso un redirect.

In breve: Strict-Transport-Security si spedisce solo sulle risposte HTTPS. I direttivi che contano sono max-age, includeSubDomains, preload. Si sale per gradi (5 minuti, una settimana, un mese), poi un anno. La preload list di Chrome non è un default: hstspreload.org scrive che il preload non è raccomandato come passo automatico, e che i prodotti non devono accendere preload da soli. Un plugin «forza HTTPS» non pubblica questo header. Verifica del 16 settembre 2026 su OWASP, MDN, RFC 6797, hstspreload.org.

Cosa trovi in questo articolo

1. Cosa fa HSTS, e cosa non è

2. L’header: tre direttivi, un solo canale

3. Perché il plugin «forza HTTPS» non basta

4. Preload: il primo carico, e perché non è un default

5. Errori da evitare

6. In sintesi

Cosa fa HSTS, e cosa non è

HTTP Strict Transport Security è definito dalla RFC 6797. Il server, su una risposta HTTPS, spedisce Strict-Transport-Security. Il browser che la rispetta, per la durata di max-age, trasforma gli URL http:// di quel dominio in https:// prima di uscire, e rifiuta di proseguire se il certificato non torna. MDN lo tratta come header di risposta; la cheat sheet OWASP, come difesa contro SSL stripping e cookie in chiaro sul primo hop.

Cinque mestieri, e cinque limiti:

Questo pezzo sta nel cluster Sicurezza, accanto al certificato e alla CSP. Tre header, tre mestieri. HSTS non cifra. Non decide quali script girano. Dice solo: questo nome, d’ora in poi, solo su TLS.

L’header: tre direttivi, un solo canale

Si spedisce sulle risposte HTTPS. Sulle risposte HTTP non si mette: la RFC lo vieta, e un header HSTS in chiaro è un header che un attaccante può scrivere lui. Il canale è l’header HTTP, su tutte le risposte del dominio che si vuole coprire, non un meta in pagina e non un file del plugin.

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

Tre pezzi:

• max-age, in secondi. È la durata del ricordo nel browser. Zero la cancella. Un anno sono 31536000. Due anni, 63072000, è l’esempio di hstspreload.org.

• includeSubDomains, opzionale ma decisivo. Senza, app.example.com resta fuori. Con, ogni sottodominio — anche quelli interni, anche quelli che «tanto non sono pubblici» — cade sotto la stessa regola.

• preload, opzionale. Non attiva la preload da sola. Segnala l’intenzione di entrare nella lista hardcoded dei browser. Senza invio su hstspreload.org, e senza i requisiti di quella lista, è una parola in più nell’header.

hstspreload.org, nelle Deployment Recommendations, indica una rampa, non un copia-incolla da due anni il primo giorno:

Si aspetta la scadenza dello stadio prima di alzare max-age. Non si salta. Un CMS con un pannello su http://old.example.com, o un webhook di un fornitore che non fa TLS, con includeSubDomains e un max-age lungo diventa un ticket, non una «best practice».

Perché il plugin «forza HTTPS» non basta

Il plugin tipico, sul CMS, fa una di queste tre cose: un 301 da HTTP a HTTPS, un rewrite nel webserver, o un Location in PHP. Tutte e tre partono da una richiesta in chiaro. hstspreload.org elenca gli attacchi che quella richiesta consente a un osservatore on-path: vedere l’URL, riscrivere il redirect, iniettare cookie sulla risposta 301. Il plugin chiude il caso felice (l’utente arriva, il server risponde, il browser segue). HSTS chiude il caso in cui qualcuno sta sul cavo.

Due mestieri, in tabella:

Il redirect resta utile: hstspreload.org lo chiede, sullo stesso host, se si ascolta sulla 80. È il gradino. Non è l’HSTS. Mettere un plugin e togliere l’header «perché adesso c’è il lucchetto» è lo stesso errore visto sui moduli anti-XSS e sulla CSP. Il costo di quei moduli sta in il costo nascosto dei plugin. Le patch restano un altro ritmo.

Preload: il primo carico, e perché non è un default

HSTS si impara alla prima risposta HTTPS. Prima di quella, il browser non sa. La preload list di Chrome — e le liste derivate di Firefox, Safari, Edge — è una lista compilata nel browser: i domini lì dentro si raggiungono solo in HTTPS, anche alla prima visita. Serve a chiudere quel buco. hstspreload.org, nella stessa pagina, scrive anche l’altra frase: i benefici del preload rispetto all’HSTS «ordinario» sono minimi, e il preload non è raccomandato come passo scontato. Molti browser oggi alzano già HTTP a HTTPS per conto loro; il preload serve soprattutto quando quell’upgrade fallisce sotto un attaccante attivo.

Requisiti per entrare dalla form di hstspreload.org, per i domini inviati da ottobre 2017:

• certificato valido;

• redirect HTTP→HTTPS sullo stesso host, se si ascolta sulla 80;

• HTTPS su tutti i sottodomini, incluso www se il record DNS c’è, e inclusi i sottodomini interni;

• header HSTS sul dominio base, in HTTPS, con max-age almeno 31536000, includeSubDomains e preload;

• se c’è un ulteriore redirect HTTPS, l’header deve stare già su quella risposta, non solo sulla pagina di arrivo.

Esempio accettato da quella pagina:

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

L’ingresso in lista non è immediato: le nuove voci finiscono nel codice di Chrome e arrivano alla stabile in mesi. L’uscita è lenta allo stesso modo. hstspreload.org: «inclusion in the preload list cannot easily be undone». I progetti che consigliano HSTS, sempre quella pagina, non devono accendere preload di default. Arrivano mail di chi l’ha trovato acceso da un pannello e ha scoperto un sottodominio senza TLS. La rimozione è un form a parte, e i browser già in circolazione restano quelli.

Per un sito da CMS, l’ordine utile è: certificato a posto, redirect 80→443, header HSTS con max-age corto, inventario dei sottodomini, rampa, e solo dopo — se si è sicuri di poter tenere HTTPS su tutto, per anni — si discute il preload. Non il contrario.

Errori da evitare

• Installare «forza HTTPS» e dichiarare chiuso il capitolo trasporto.

• Spedire HSTS su HTTP.

• Accendere preload il primo giorno, o lasciarlo come default di un plugin.

• Mettere includeSubDomains senza un inventario: staging, mail, pannello, API, il sottodominio del fornitore.

• Confondere HSTS, certificato TLS, CSP e WAF.

• Credere che togliere preload dall’header cancelli il dominio dalle liste già spedite nei browser.

• Un max-age da due anni copiato da un blog, senza la rampa.

In sintesi

HSTS è un header HTTPS, Strict-Transport-Security, con un max-age. Il plugin che forza il lucchetto è un redirect. Si usano insieme, in quest’ordine: TLS valido, 301 sulla 80, header con rampa, sottodomini sotto controllo. Il preload è una lista nei browser, lenta da entrare e lenta da uscire, non un flag da CMS. Non sostituisce il certificato. Non sostituisce la CSP.

Fonti

• IETF, RFC 6797, HTTP Strict Transport Security (HSTS).

• MDN, Strict-Transport-Security (consultata il 16 settembre 2026).

• OWASP, HTTP Strict Transport Security Cheat Sheet.

• Chrome / hstspreload.org, HSTS Preload List Submission: rampa di max-age, requisiti, «preloading is not recommended» come default, divieto di preload silenzioso nei prodotti.

Immagine di copertina: retro di un rack in un data center (NERSC). L’HSTS si spedisce dal server, su tutte le risposte HTTPS, non da un plugin in pagina. Foto di Derrick Coetzee, Wikimedia Commons, licenza CC0.

Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.