Header di sicurezza HTTP spiegati: HSTS, CSP e altri

Che cosa sono gli header di sicurezza

Ogni risposta HTTP inizia con gli header: coppie nome-valore come Content-Type: text/html. Alcuni di essi cambiano il modo in cui il browser tratta la pagina. Inviarli non costa nulla, valgono per ogni visitatore e si impostano sul server, sulla piattaforma di hosting o su una rete di distribuzione dei contenuti (CDN), non nell’HTML della pagina.

IPNixa imposta i propri header in un file _headers che Cloudflare invia con ogni pagina. Lo strumento di questo sito richiede dal nostro server l’indirizzo che inserisci, segue fino a tre reindirizzamenti e legge gli header della risposta finale.

I sei header più importanti

Questi sono gli header valutati dallo strumento. I valori indicati sono punti di partenza comuni e sicuri; adattali alle esigenze del tuo sito.

Come lo strumento di IPNixa valuta ogni header

Ogni header riceve uno di tre stati: presente, da verificare o non fornito. «Da verificare» significa che l’header esiste ma il suo valore non rispetta la regola indicata sotto: è un invito a guardare meglio, non un punteggio di sicurezza.

• HSTS è presente quando compare una sola volta con un max-age di almeno 15552000 secondi (180 giorni). Un max-age più breve o pari a zero viene segnalato come da verificare.
• CSP è presente quando controlla gli script tramite script-src o default-src e non contiene 'unsafe-inline', 'unsafe-eval' o un * isolato in nessun punto della policy. Una policy report-only viene indicata come non fornita, perché non blocca nulla.
• Il controllo dei frame è presente con una direttiva frame-ancestors limitata a 'none', 'self' o a indirizzi esatti, oppure con X-Frame-Options impostato su DENY o SAMEORIGIN.
• X-Content-Type-Options è presente solo con il valore nosniff.
• Referrer-Policy è presente quando l’ultimo valore è no-referrer, same-origin, strict-origin o strict-origin-when-cross-origin. I browser usano l’ultimo valore che riconoscono, quindi un elenco viene valutato in base alla voce finale.
• Permissions-Policy è presente se viene inviato, qualunque sia il contenuto, perché l’elenco corretto di funzionalità dipende dal sito.

Cosa inviano i siti reali: un campione

Il 2 novembre 2026 abbiamo richiesto cinque home page con lo stesso user agent usato dallo strumento e abbiamo valutato le risposte con le regole di IPNixa. Gli header cambiano spesso, quindi consideralo un’istantanea.

Leggere il campione: da verificare non vuol dire debole

La policy di GitHub limita gli script al proprio host di risorse e a hash specifici, ed è quindi rigorosa. Viene segnalata come da verificare solo perché il suo style-src consente 'unsafe-inline', e la regola cerca quella parola chiave in qualsiasi punto della policy. Gli stili inline comportano un rischio molto minore degli script inline: si tratta quindi di un compromesso deliberato più che di una falla.

Il nostro sito è segnalato come da verificare per un motivo diverso: la sua policy contiene solo frame-ancestors 'none', che blocca l’incorporamento in frame ma non limita gli script. Riportiamo il risultato così com’è.

La home page di Google invia la sua policy sugli script come Content-Security-Policy-Report-Only, che segnala le violazioni senza bloccarle, e in questa risposta non inviava HSTS; i grandi siti possono imporre HTTPS con altri mezzi, come gli elenchi di precaricamento dei browser. Il portale di Wikipedia invia un max-age HSTS molto lungo e poco altro su quella pagina. Niente di tutto ciò indica se questi siti siano sicuri nel complesso; mostra quali protezioni del browser richiede ciascuna risposta.

Aggiungere gli header al tuo sito

Aggiungi un header alla volta, ricarica il sito e verifica che pagine, accessi, video incorporati e moduli di pagamento funzionino ancora prima di aggiungere il successivo.

1. Inizia dagli header a basso rischio: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin e X-Frame-Options: DENY, a meno che le tue pagine non debbano essere incorporate in un frame da un altro sito.
2. Aggiungi HSTS con un max-age breve, per esempio 300, verifica che ogni sottodominio funzioni in HTTPS, poi portalo a 31536000. Aggiungi includeSubDomains solo quando tutti i sottodomini supportano HTTPS.
3. Scrivi una Content-Security-Policy e inviala prima come Content-Security-Policy-Report-Only. Raccogli le segnalazioni di violazione o osserva la console del browser, correggi o autorizza le sorgenti legittime, poi passa all’header che applica la policy.
4. Aggiungi Permissions-Policy elencando le funzionalità sensibili che non usi, per esempio camera=(), microphone=(), geolocation=().
5. Su nginx usa add_header con il flag always, su Apache usa Header always set, e su hosting statico o CDN usa il file degli header della piattaforma o le regole per gli header di risposta.
6. Esegui di nuovo il controllo degli header di IPNixa. Per ogni header mancante mostra una riga pronta da copiare per nginx, Apache o un file _headers.

Precaricamento HSTS e altre cautele

Gli elenchi di precaricamento HSTS (preload) sono integrati nei browser, quindi anche la primissima visita usa HTTPS. Per inviare un dominio servono un max-age di almeno un anno, includeSubDomains e la direttiva preload, e la rimozione richiede mesi prima di arrivare agli utenti. Invia il dominio solo se tutti i sottodomini, compresi quelli interni, resteranno su HTTPS.

X-XSS-Protection è obsoleto: i browser moderni lo ignorano e una CSP lo sostituisce. Gli header di isolamento cross-origin (Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy e Cross-Origin-Resource-Policy) non vengono valutati dallo strumento, perché servono solo ai siti che usano funzionalità come la memoria condivisa, e attivarli può bloccare i contenuti incorporati di terze parti.