Security

HTTP Headers

Visualizza header di risposta e verifica policy di sicurezza.

Informazioni su questo strumento

HTTP Headers recupera il tuo URL con una vera richiesta HTTPS, cattura ogni header nella risposta (e ogni risposta intermedia lungo qualsiasi catena di redirect) ed esegue il risultato attraverso un audit di sicurezza che copre i moderni header di hardening: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options / CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy e Permissions-Policy. Ogni header viene verificato per presenza, validità del valore e lacune rispetto alle best practice.

Oltre all'audit, elenchiamo ogni header testualmente così puoi confermare la policy di caching (Cache-Control, ETag, Vary), il tracciamento CDN (CF-Ray, X-Cache, X-Served-By), la compressione (Content-Encoding: br/gzip) e qualsiasi header personalizzato che il tuo stack emette. Il metodo HTTP (GET o HEAD), la versione HTTP negoziata (HTTP/1.1, HTTP/2, HTTP/3) e la versione TLS sono riportati nella barra della richiesta.

Quando usare questo strumento

  • Hardening della sicurezza. Prima del go-live, conferma che HSTS, CSP e gli altri siano impostati con valori sicuri — baseline Mozilla Observatory come minimo.
  • Debug della cache. Vedi esattamente quale Cache-Control e Vary emette il tuo CMS o framework — causa comune di "la vecchia versione che resta in giro".
  • Audit della catena di redirect. Individua catene accidentali 302-poi-301, loop HTTP-verso-HTTPS-verso-host-diverso e canonicalizzazione mancante.
  • Comportamento CDN. Conferma che Cloudflare/Fastly/CloudFront stia effettivamente memorizzando nella cache ciò che pensi leggendo Age, X-Cache e gli header specifici della CDN.

Cosa copre il nostro audit di sicurezza

Per ognuno dei sei header di hardening riportiamo: presente o mancante, il valore effettivo e un breve verdetto ("buono", "da rafforzare", "vulnerabile"). HSTS senza includeSubDomains, CSP con unsafe-inline o Referrer-Policy lasciato al default vengono segnalati. Non ti diciamo mai la policy "perfetta" perché ogni sito è diverso — ma ti diciamo quali manopole sono ancora alle impostazioni di fabbrica.

Domande frequenti

Cos'è HSTS e perché è importante?

Strict-Transport-Security dice al browser "usa sempre HTTPS per questo dominio, anche se l'utente ha digitato http:// o ha cliccato un link http://". Una volta impostato con un max-age ragionevole (tipicamente 31536000 = 1 anno), previene attacchi di SSL stripping nelle visite successive. Aggiungere includeSubDomains estende la protezione a ogni sottodominio — default forte per la maggior parte dei siti ma assicurati che tutti supportino davvero HTTPS prima.

Manca la mia CSP — quanto è pericoloso?

Senza CSP, qualsiasi falla XSS nel tuo sito viene eseguita con piena potenza: può esfiltrare cookie, caricare script controllati dall'attaccante o riscrivere il DOM. Una CSP iniziale di default-src 'self' blocca i payload XSS più comuni (script inline, caricamenti di script esterni) a costo quasi zero. Policy più strette che bandiscono completamente gli script inline richiedono refactoring ma offrono una protezione molto più forte.

Seguite i redirect?

Sì — fino a cinque hop. Ogni passo è mostrato con il suo metodo, status, location e header così puoi individuare hop a protocollo misto (HTTP→HTTPS), canonicalizzazione mancante (apex vs www) o loop accidentali. La maggior parte dei siti in produzione dovrebbe reindirizzare al massimo una volta (HTTP → HTTPS), poi servire i contenuti; più di due hop è di solito un segno di regole di rewrite sovrapposte.

Perché lo strumento mostra HTTP/2 anche se ho configurato HTTP/3?

HTTP/3 (QUIC su UDP) richiede che il client opti tramite l'header Alt-Svc alla prima connessione. Il nostro checker usa HTTP/2 su TCP per default, che è ciò che la maggior parte dei client HTTP fa ancora oggi; se il tuo server pubblicizza HTTP/3 in Alt-Svc, vedrai quell'header nel risultato, ma la risposta stessa è ancora su HTTP/2. La presenza di Alt-Svc è la cosa giusta da cercare.