Intestazioni di sicurezza HTTP
Verifica se il tuo sito ha correttamente configurate le intestazioni di sicurezza HTTP.
Come funziona il controllo degli header
Lo strumento invia una normale richiesta HTTPS GET all'URL che inserisci e legge gli header della risposta - gli stessi header che riceve ogni browser. Non viene analizzato nulla nel corpo della pagina; gli header di sicurezza vivono interamente nella risposta HTTP.
Cerchiamo poi gli header che controllano le protezioni lato browser: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options e Referrer-Policy. Ogni header presente aumenta il punteggio, e quelli mancanti vengono elencati con una spiegazione del rischio che lasciano aperto.
Poiché il controllo segue i redirect, il risultato riflette l'URL finale. Se il tuo sito reindirizza da HTTP a HTTPS o dal dominio radice a www, gli header che vedi appartengono alla destinazione.
Come leggere i risultati
Il punteggio è un orientamento rapido, non una certificazione. Cosa conta nella pratica:
- HSTS - dice ai browser di usare sempre HTTPS per il tuo dominio. Un max-age di almeno sei mesi è prassi comune; aggiungi includeSubDomains solo se ogni sottodominio serve HTTPS.
- CSP - la difesa più forte contro gli XSS, ma anche la più difficile da scrivere. Anche una policy di base che limita le sorgenti degli script è un grande passo avanti rispetto a niente.
- X-Content-Type-Options: nosniff e X-Frame-Options (o la direttiva CSP frame-ancestors) - protezioni economiche da una riga contro il MIME sniffing e il clickjacking.
Problemi comuni
Header configurato, ma segnalato come mancante. Un reverse proxy o un CDN davanti alla tua applicazione può rimuovere o sovrascrivere gli header. Confronta la risposta via curl -I direttamente contro l'origine e contro l'URL pubblico per scoprire quale livello lo elimina.
CSP presente, ma inefficace. Content-Security-Policy-Report-Only registra le violazioni senza bloccare nulla. È utile per i test, ma non offre alcuna protezione - passa all'header effettivo quando il tuo log dei report è pulito.
Route diverse restituiscono header diversi. Gli header impostati nel middleware applicativo potrebbero non applicarsi ai file statici serviti direttamente dal web server, né alle pagine di errore. Testa anche l'URL di una risorsa statica e una pagina 404.
Domande frequenti
Quali header di sicurezza dovrebbe avere ogni sito web?
Una base ragionevole: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy e una protezione dal framing via X-Frame-Options o CSP frame-ancestors. Le API beneficiano in più di Cache-Control: no-store sulle risposte sensibili.
L'header X-XSS-Protection serve ancora?
No. I browser moderni hanno rimosso l'auditor XSS che controllava, e nei browser vecchi l'header poteva addirittura introdurre vulnerabilità. Usa piuttosto una Content-Security-Policy rigorosa.
HSTS protegge la primissima visita?
Non da solo - il browser impara la regola solo dalla prima risposta HTTPS. Per coprire la prima visita, invia il tuo dominio alla lista di preload HSTS (hstspreload.org) e usa la direttiva preload insieme a includeSubDomains.
Un header sbagliato può rompere il mio sito?
Sì, due casi classici: una CSP troppo rigida blocca i tuoi stessi script o stili inline, e HSTS con includeSubDomains rompe qualsiasi sottodominio che gira ancora in HTTP semplice. Distribuisci la CSP prima in modalità report-only e inizia HSTS con un max-age breve.
Monitora i cambiamenti delle intestazioni continuamente
ePulz.io ti avvisa quando un'intestazione cambia (ad esempio dopo un deploy che ha rimosso CSP per errore).
Inizia con ePulz.io →Informazioni su questo strumento
Le intestazioni di sicurezza indicano al browser come proteggere i tuoi visitatori. Questo controllo verifica se HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options e Referrer-Policy sono effettivamente presenti e assegna un punteggio al risultato, così puoi individuare le lacune di clickjacking e MIME-sniffing dopo un rilascio.