Security

HTTP Headers

Visualizza header di risposta e verifica policy di sicurezza.

URL http or https (default https). Up to 3 redirects are followed.

Try: github.com cloudflare.com example.com mozilla.org

https://example.com/

Status: 200 HTTP/1.1 88 ms

Security grade

Score

0 / 100

Status

200

Protocol

HTTP/1.1

Latency

88 ms

Security audit

fail Strict-Transport-Security? +0/25

No HSTS header — a downgrade attack on a public Wi-Fi can redirect the user to plaintext HTTP.
fail Content-Security-Policy? +0/25

No CSP — a single XSS bug can execute arbitrary scripts on this origin.
fail X-Frame-Options / frame-ancestors? +0/15

Page can be framed by any site — vulnerable to clickjacking.
fail X-Content-Type-Options +0/10

nosniff is missing — IE/old-Edge may execute disguised scripts based on content sniffing.
fail Referrer-Policy? +0/15

No Referrer-Policy — full URLs (including query strings) leak to every clicked link.
fail Permissions-Policy? +0/10

No Permissions-Policy — third-party iframes can request sensitive features without restriction.

Response headers

date: Sun, 26 Jul 2026 18:12:57 GMT content-type: text/html transfer-encoding: chunked connection: keep-alive server: cloudflare last-modified: Tue, 21 Jul 2026 07:16:00 GMT allow: GET, HEAD accept-ranges: bytes age: 9 cf-cache-status: HIT cf-ray: a21560248c6271cb-FRA

What does each field mean?

Field reference

Voto di sicurezza

Punteggio aggregato sugli header di sicurezza pesato per impatto: HSTS e CSP pesano di più. A+ richiede che tutti e cinque gli header siano impostati correttamente; F significa che nessuno è presente. Lo usi come prima indicazione rapida, poi approfondisca i risultati per singolo header.

Protocollo HTTP

HTTP/1.1 è il vecchio protocollo testuale. HTTP/2 multiplexa più stream su una singola connessione TCP (compressione degli header, server push). HTTP/3 viaggia su QUIC (UDP) — migliore su reti instabili o mobili. Un server moderno dovrebbe esporre almeno HTTP/2.

Latenza

Round-trip dal nostro server al target fino all'arrivo del primo byte di risposta. Non è un benchmark CDN — distanza geografica, handshake TLS e warm-up del server influiscono. Da usare come indicatore grezzo di freschezza, non come dato di performance reale.

Catena di redirect

Una catena lunga (3+ redirect) penalizza SEO e performance. Il pattern classico è <code>http://example.com → https://example.com → https://www.example.com</code>: due salti, accettabile. Oltre cinque è una configurazione errata.

Strict-Transport-Security (HSTS)

HSTS dice al browser "non collegarti più a me in HTTP in chiaro". <code>max-age=15768000</code> (6 mesi) è il minimo pratico; <code>includeSubDomains; preload</code> consente l'inclusione nella preload list globale. Una volta nel preload non si può uscire per ~12 mesi — prima sistemi tutto il resto.

Content-Security-Policy (CSP)

CSP autorizza da dove possono essere caricati script, stili, immagini e frame. <code>default-src 'self'</code> è una base ragionevole; <code>script-src</code> con nonce è la configurazione più robusta. Eviti <code>unsafe-inline</code> e <code>unsafe-eval</code> — annullano gran parte della protezione XSS di CSP. Usi report-uri / report-to per il monitoraggio.

X-Frame-Options

Imposti <code>DENY</code> per vietare qualsiasi framing, oppure <code>SAMEORIGIN</code> per consentire solo frame di origine identica. L'equivalente moderno è <code>frame-ancestors</code> in CSP (sintassi più ricca) — entrambe le scelte soddisfano il nostro audit.

Referrer-Policy

Determina cosa il browser invia nell'header <code>Referer</code>. <code>strict-origin-when-cross-origin</code> (default nei browser moderni) è una buona baseline: URL completo same-origin, solo origine cross-origin, niente in caso di downgrade. <code>no-referrer</code> rimuove tutto; <code>unsafe-url</code> fa trapelare l'URL completo in downgrade — da evitare.

Permissions-Policy

Successore di Feature-Policy. Permette di consentire / negare le API del browser per origine: <code>camera=(), microphone=(), geolocation=(self)</code>. È soprattutto defense-in-depth; applicato anche agli iframe, garantendo un comportamento più sicuro per i contenuti incorporati.

X-Content-Type-Options: nosniff

Senza questo header il browser può eseguire una risposta JSON come JavaScript se "sembra uno script". Impostare <code>X-Content-Type-Options: nosniff</code> obbliga a rispettare il Content-Type dichiarato. Header poco costoso, sempre sicuro da attivare — non c'è ragione valida per ometterlo.

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.