HSTS e altre intestazioni di sicurezza: cosa sono, con prudenza

Una volta che il sito funziona stabilmente in HTTPS, puoi fare un ulteriore passo avanti: dire al browser, tramite alcune intestazioni HTTP, come comportarsi con le tue pagine. La più nota è HSTS, ma ce ne sono altre utili. Sono strumenti efficaci, ma vanno usati con prudenza: un’intestazione impostata male può rendere il sito irraggiungibile o rompere funzioni importanti. In questo articolo vediamo cosa fanno, come introdurle gradualmente e quali errori evitare.

Cosa sono le intestazioni HTTP

Ogni volta che il browser chiede una pagina, il server risponde con il contenuto e con una serie di intestazioni (header): piccole righe di informazioni che il visitatore non vede, ma che il browser legge. Alcune indicano il tipo di contenuto o le regole di cache; altre, quelle di sicurezza, chiedono al browser di attivare protezioni aggiuntive.

Puoi vedere le intestazioni del tuo sito con gli strumenti per sviluppatori del browser: premi F12, apri la scheda Rete (Network), ricarica la pagina, clicca sulla prima richiesta (il documento principale) e guarda la sezione delle intestazioni di risposta.

HSTS: Strict-Transport-Security

Cosa fa

Anche con un reindirizzamento da http:// a https://, la primissima richiesta di un visitatore che digita l’indirizzo senza protocollo può partire in chiaro. È un piccolo spiraglio, ma esiste. Con l’intestazione HSTS il sito dice al browser: «per i prossimi N secondi, collegati a me solo in HTTPS». Da quel momento il browser trasforma da solo ogni richiesta http:// in https://, senza nemmeno provare la connessione in chiaro.

Un esempio di intestazione:

Strict-Transport-Security: max-age=31536000

dove max-age è la durata in secondi (in questo esempio un anno).

Perché serve prudenza

HSTS ha un effetto collaterale importante: mentre è attivo, il browser non permette di ignorare un errore del certificato. Se per qualunque motivo il certificato diventasse non valido, i visitatori che hanno già ricevuto l’intestazione non potrebbero entrare nemmeno cliccando su «procedi comunque». E il browser ricorda la regola fino alla scadenza di max-age: non basta togliere l’intestazione dal server per annullarne subito l’effetto.

Le opzioni aggiuntive

includeSubDomains: estende la regola a tutti i sottodomini. Attenzione: se anche un solo sottodominio (un vecchio gestionale, un servizio di terzi, un’area riservata) non funziona in HTTPS, diventerà irraggiungibile per chi ha ricevuto l’intestazione. Aggiungila solo dopo aver controllato ogni sottodominio, compresi quelli che non usi spesso, come webmail.tuodominio.it.
preload: indica la volontà di inserire il dominio in una lista integrata direttamente nei browser. È un impegno di lungo periodo: uscire dalla lista è lento e non immediato. Per la maggior parte dei siti non è necessario e sconsigliamo di attivarlo senza una valutazione accurata.

Come introdurlo gradualmente

assicurati che il sito funzioni in HTTPS su tutte le pagine, senza contenuti misti e con il reindirizzamento attivo;
inizia con un max-age breve, per esempio 300 secondi (5 minuti);
naviga il sito per qualche giorno e verifica che tutto funzioni;
aumenta progressivamente: un giorno, una settimana, un mese, e infine il valore definitivo;
valuta includeSubDomains solo alla fine, dopo aver controllato tutti i sottodomini.

Le altre intestazioni di sicurezza

X-Content-Type-Options

X-Content-Type-Options: nosniff

Impedisce al browser di «indovinare» il tipo di un file diverso da quello dichiarato dal server, evitando che un file caricato come immagine venga interpretato come script. È tra le più semplici e sicure da attivare: raramente crea problemi.

X-Frame-Options e frame-ancestors

X-Frame-Options: SAMEORIGIN

Impedisce ad altri siti di incorporare le tue pagine dentro un riquadro (iframe), una tecnica usata per ingannare gli utenti e far loro cliccare su elementi nascosti. Con SAMEORIGIN le tue pagine possono essere incorporate solo dal tuo stesso sito. Attenzione se un servizio esterno legittimo deve mostrare il tuo sito in un riquadro: in quel caso va valutata con più cura. L’equivalente moderno è la direttiva frame-ancestors della Content-Security-Policy.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Stabilisce quante informazioni sulla pagina di provenienza vengono passate quando un visitatore clicca un link verso un altro sito. Il valore indicato invia solo il dominio (non il percorso completo) verso siti esterni, ed è già il comportamento predefinito dei browser moderni. Impostarlo esplicitamente rende la scelta chiara.

Permissions-Policy

Permissions-Policy: camera=(), microphone=(), geolocation=()

Permette di disattivare funzioni del browser che il sito non usa, come fotocamera, microfono o posizione. Se il tuo sito usa una di queste funzioni (ad esempio una mappa che chiede la posizione), non bloccarla.

Content-Security-Policy

È la più potente e la più delicata. Permette di elencare da quali origini il browser può caricare script, stili, immagini, font e così via, bloccando tutto il resto. Ben configurata è un’ottima difesa; configurata male blocca analytics, mappe, sistemi di pagamento, chat e plugin. Su siti con molti servizi esterni, come un e-commerce, richiede un lavoro attento.

Due consigli pratici:

esiste una variante «di sola osservazione», Content-Security-Policy-Report-Only, che segnala le violazioni nella console del browser senza bloccare nulla: è il modo giusto per iniziare;
la direttiva upgrade-insecure-requests chiede al browser di caricare in HTTPS le risorse indicate in HTTP: può aiutare con i contenuti misti, ma non sostituisce la loro correzione.

Un’intestazione da non usare più

X-XSS-Protection compare ancora in molte guide, ma è stata abbandonata dai browser moderni e può persino essere controproducente. Non serve aggiungerla.

Come impostarle

Sui siti che usano il file .htaccess, le intestazioni si possono aggiungere con la direttiva Header. Un esempio prudente da cui partire:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=300"
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Alcune indicazioni:

fai prima un backup del file .htaccess, così puoi tornare indietro subito;
verifica che un plugin di sicurezza o di cache non imposti già le stesse intestazioni: valori doppi o in conflitto creano comportamenti imprevedibili;
su PrestaShop, metti le regole fuori dal blocco che il CMS rigenera automaticamente (prima di # ~~start~~);
dopo ogni modifica controlla le intestazioni dagli strumenti per sviluppatori e naviga le pagine più importanti: home, carrello, checkout, area riservata, moduli di contatto.

Se il sito è sotto la rete iWebLab Edge

Quando il sito è servito dalla rete iWebLab Edge, le pagine possono arrivare al visitatore dalla cache dei punti di presenza. Dopo aver cambiato le intestazioni, svuota la cache del plugin o modulo di cache e controlla dal browser che i visitatori ricevano davvero i valori nuovi. Se qualcosa non corrisponde, apri un ticket prima di fare altre modifiche.

Gli errori da evitare

attivare HSTS con max-age lungo, includeSubDomains e preload il primo giorno, «perché lo dice una guida»;
copiare una Content-Security-Policy da un altro sito: ogni sito ha le sue risorse;
cercare di «prendere il massimo punteggio» in uno strumento di analisi delle intestazioni a costo di rompere funzioni reali;
dimenticare i sottodomini meno usati quando si estende HSTS.

Una prospettiva corretta

Le intestazioni di sicurezza sono un buon complemento, non la difesa principale. Per proteggere davvero il sito contano gli aggiornamenti, i backup e gli strumenti attivi sui nostri piani, come cPGuard, Security Intelligence e la gestione delle vulnerabilità.

Se vuoi introdurre HSTS o una Content-Security-Policy e non sei sicuro dei valori giusti per il tuo sito, apri un ticket dall’area clienti: meglio un controllo in più prima che un sito irraggiungibile dopo.