Verificatore Header HTTP
Un verificatore di header HTTP interroga un URL e mostra gli header di risposta che il server restituisce: il codice di stato, i campi di cache e di cookie e gli header di sicurezza che il browser applica. Questo aggiunge un punteggio da 0 a 100 calcolato su sette di essi: HSTS, CSP, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy e Permissions-Policy. Per github.com restituisce 200 OK in circa 60 ms, 17 header e 90/100, voto A+.
Header di Sicurezza
Tutti gli Header di Risposta
| Header | Value |
|---|---|
Che cosa mostra questo verificatore di header HTTP?
Digita un dominio: lo strumento invia dal nostro server una richiesta HEAD a quell'indirizzo e poi mostra il codice di stato, il tempo di andata e ritorno in millisecondi, l'elenco completo degli header di risposta e un punteggio di sicurezza da 0 a 100 costruito su HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy e Permissions-Policy. Riporta ciò che il server ha inviato: non segue i redirect e non legge il corpo della pagina.
Strumenti popolari
Informazioni su Verificatore Header HTTP
Questo verificatore di header HTTP prende un URL, gli invia una richiesta HEAD dal nostro server e mostra ciò che torna indietro: il codice di stato con la relativa frase, il tempo di andata e ritorno in millisecondi e ogni header di risposta inviato dal server. Per github.com sono 200 OK in circa 60 ms e 17 campi, da content-type ed etag fino al valore completo di content-security-policy.
La scheda Punteggio di Sicurezza valuta sette header su 100. Strict-Transport-Security e Content-Security-Policy valgono 20 punti ciascuno, X-Content-Type-Options e X-Frame-Options 15 ciascuno, mentre X-XSS-Protection, Referrer-Policy e Permissions-Policy ne valgono 10. Da 90 punti in su il voto è A+, 80 dà A, 70 B, 60 C, 40 D e sotto F. github.com ottiene 90/100 perché manca Permissions-Policy; example.com non invia nessuno dei sette e resta a 0.
Il punteggio misura la presenza, non la qualità. Il valore x-xss-protection: 0 disattiva quel filtro e incassa comunque i suoi dieci punti, mentre un header content-security-policy-report-only non ne porta nessuno: leggi quindi i valori stampati sotto ogni riga contrassegnata Present invece di fidarti del solo voto. I redirect non vengono seguiti: google.com risponde 301 con location: https://www.google.com/, e bisogna incollare quell'indirizzo per valutare la destinazione. La richiesta è di tipo HEAD, quindi non viene analizzato alcun HTML, meta tag o testo della pagina; si arrende dopo dieci secondi e da uno stesso indirizzo vengono accettate venti verifiche al minuto.
L'URL che digiti viene inviato al server di questo sito, che effettua la richiesta al posto tuo con lo user agent FreeWebTools Header Checker/1.0 e senza i tuoi cookie o la tua sessione: vedi quindi ciò che riceve un visitatore anonimo. Gli intervalli di indirizzi IP privati e riservati, localhost, gli endpoint dei metadati cloud e le porte amministrative come 22, 3306 e 6379 vengono rifiutati.
Casi d'uso
Come verificare gli header di risposta HTTP di un sito
Digita un dominio o un indirizzo completo nel campo di ricerca, per esempio example.com: il prefisso https:// viene aggiunto per te. Puoi anche cliccare uno degli esempi accanto a Prova: google.com, github.com, cloudflare.com o stackoverflow.com.
Premi Invio o clicca su Verifica. La richiesta parte dal nostro server come richiesta HEAD, quindi tornano solo gli header, mai il corpo della pagina.
Leggi le tre schede di riepilogo: Codice di Stato con la relativa frase, Punteggio di Sicurezza su 100 con il voto in lettera e Tempo di Risposta in millisecondi.
Scorri Header di Sicurezza per vedere quali fra HSTS, CSP, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy e Permissions-Policy sono contrassegnati Present o Missing, e leggi il valore mostrato sotto ognuno di quelli presenti.
Apri Tutti gli Header di Risposta per leggere nome e valore di ogni header restituito dal server, compresi i campi di cache, cookie e CDN che il punteggio non copre.
Clicca su Copia per mettere l'intero report — URL, stato, punteggio con il voto ed elenco degli header — negli appunti come testo semplice.
Suggerimenti Pro
- Digita solo il dominio: il campo aggiunge https:// al posto tuo, quindi github.com viene verificato come https://github.com. Scrivi http:// in modo esplicito per vedere la risposta in HTTP semplice, dove strict-transport-security di norma manca perché la RFC 6797 impone ai browser di ignorarlo su una connessione non sicura.
- Il punteggio premia la presenza, non il valore. github.com invia x-xss-protection: 0, che disattiva il filtro, e incassa comunque i dieci punti pieni: leggi la riga grigia con il valore sotto ogni voce contrassegnata Present prima di fidarti del voto.
- Una policy in modalità report-only non porta punti. google.com invia content-security-policy-report-only senza una policy applicata e perde così tutti i 20 punti della CSP; l'etichetta Present compare solo per il nome di header esatto content-security-policy.
- Quando la scheda Codice di Stato mostra 301 o 302, copia il valore location dalla tabella degli header e lancia una seconda verifica su di esso. La risposta di redirect in sé non porta quasi nessun header di sicurezza, ed è per questo che google.com si ferma a 25/100.
- Il pulsante Copia mette l'intero report negli appunti come testo semplice — URL, stato, punteggio con il voto e ogni header — ed è quello che incolli in un ticket. Distribuisci il lavoro in serie su venti verifiche al minuto; oltre, l'API risponde 429 e la pagina mostra un messaggio di errore generico.
Risoluzione dei problemi
La pagina mostra «Failed to check headers. Please verify the URL is accessible.» anche se il sito si apre normalmente nel browser.
Questo messaggio generico compare quando la risposta è tornata inutilizzabile. La causa più frequente è il limite di frequenza: oltre venti verifiche al minuto dallo stesso indirizzo, l'API risponde 429 Too Many Requests. Aspetta un minuto e riprova. Lo stesso messaggio compare quando il server impiega più dei dieci secondi di timeout per rispondere alla richiesta HEAD.
La riga di errore dice «Connection failed: SSL certificate problem: certificate has expired».
Il certificato viene verificato e non accettato alla cieca, quindi un certificato scaduto, autofirmato o emesso per un altro nome host interrompe la verifica invece di produrre un report fuorviante. Rinnova o correggi il certificato, oppure verifica l'indirizzo in http:// per leggere gli header che il server invia prima che entri in gioco TLS.
La riga di errore dice «Internal URLs not allowed», «Private IPs not allowed» oppure «This port is not allowed».
Lo strumento rifiuta localhost, gli intervalli di IP privati e riservati, gli endpoint dei metadati cloud e le porte 22, 23, 25, 3306, 5432, 6379, 11211, 27017, 8080 e 8443, per non diventare uno scanner di rete interna. Usa un nome host risolvibile pubblicamente sulla porta 80 o 443; per un server locale esegui curl -I sulla macchina stessa.
La scheda Codice di Stato mostra 301 o 302, pochi header e un punteggio di sicurezza basso.
I redirect non vengono seguiti di proposito, quindi quello che stai valutando è la risposta di redirect, non la destinazione. google.com risponde 301 con location: https://www.google.com/ e per questo si ferma a 25/100. Copia il valore location dalla tabella degli header e lancia una seconda verifica su di esso per valutare la pagina su cui i visitatori atterrano davvero.
La riga di errore dice «Connection failed: Could not resolve host».
Il nostro server non ha trovato alcun record DNS pubblico per quel nome host. Controlla l'ortografia, elimina lo spazio o le virgolette finite nell'indirizzo incollato e verifica che il dominio si risolva anche fuori dalla tua rete. Un host che esiste solo nel tuo file hosts, dietro una VPN o su un resolver interno non è raggiungibile da qui.
Domande frequenti
Digita il dominio nel campo in cima a questa pagina e premi Invio oppure il pulsante Verifica. Il nostro server invia una richiesta HEAD a quell'URL e la pagina riempie tre schede — Codice di Stato, Punteggio di Sicurezza e Tempo di Risposta — seguite dall'analisi Header di Sicurezza e da una tabella con tutti gli header ricevuti. github.com risponde 200 OK in circa 60 ms con 17 campi. Non servono estensioni, comandi curl né strumenti per sviluppatori.
Un header HTTP è una riga fatta di nome e valore che accompagna una richiesta o una risposta per descriverla. content-type: text/html; charset=utf-8 indica il tipo di media, cache-control indica per quanto tempo la risposta può essere riutilizzata, location nomina la destinazione di un redirect. La RFC 9110, HTTP Semantics, definisce la sintassi dei campi e il registro dei loro nomi. Gli header viaggiano accanto al corpo, mai al suo interno; questa pagina elenca solo header di risposta.
I sette valutati qui sono Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy e Permissions-Policy. HSTS e CSP pesano 20 punti ciascuno, X-Content-Type-Options e X-Frame-Options 15 ciascuno, gli altri tre 10 ciascuno. MDN segnala X-XSS-Protection come deprecato e non standard e raccomanda al suo posto una Content-Security-Policy solida: considera quei dieci punti un residuo storico, non un obiettivo.
Avvia la verifica e leggi la sezione Header di Sicurezza: ognuno dei sette porta un'etichetta Present o Missing, una descrizione di una riga e, se presente, il valore esatto restituito dal server. La scheda Punteggio di Sicurezza traduce tutto in 0-100 con un voto: da 90 in su è A+, 80 è A, 70 B, 60 C, 40 D e sotto 40 F. github.com arriva a 90/100, con il solo Permissions-Policy mancante.
Premi F12 per aprire gli strumenti per sviluppatori, passa alla scheda Rete, ricarica la pagina, clicca la richiesta del documento e leggi il pannello degli header di risposta. Lì vedi ciò che ha ricevuto il tuo browser, cookie e negoziazione del contenuto compresi. Questa pagina è la controparte neutra: la richiesta parte dal nostro server con lo user agent FreeWebTools Header Checker/1.0 e senza cookie, quindi vedi ciò che riceve un visitatore anonimo.
Gli header portano tutto ciò che in un messaggio non è il corpo: l'esito del trasferimento, il tipo di media e la codifica, le regole di cache e rivalidazione, i cookie e le policy di sicurezza che il browser deve applicare. Senza content-type il browser deve indovinare il formato; senza strict-transport-security può continuare a parlare HTTP in chiaro; senza content-security-policy uno script iniettato viene eseguito indisturbato. Il corpo da solo non può esprimere nulla di tutto questo.
Ogni campo occupa una riga: nome, due punti, uno spazio facoltativo e il valore, come in x-frame-options: deny. La RFC 9110, sezione 5.1, rende i nomi dei campi indipendenti da maiuscole e minuscole, e HTTP/2 li impone in minuscolo: per questo la tabella qui sopra mostra content-type e non Content-Type. Un campo può legittimamente ripetersi; in quel caso questo verificatore conserva l'ultimo valore che analizza.
Sì. TLS cifra l'intero messaggio HTTP, header inclusi: chi osserva la rete vede l'indirizzo IP di destinazione e il nome host nell'SNI, ma non i nomi dei campi, i valori o i cookie. In HTTP semplice non è protetto nulla, ed è proprio il problema che affronta Strict-Transport-Security: la RFC 6797 impone al browser di usare HTTPS per quell'host per tutta la durata di max-age, e i browser ignorano l'header se arriva via HTTP.
I nomi dei campi no. La RFC 9110, sezione 5.1, stabilisce che i nomi dei campi sono indipendenti da maiuscole e minuscole: Content-Type e content-type sono lo stesso campo, e HTTP/2 impone la forma minuscola. I valori sono un'altra storia: un browser accetta sia x-frame-options: DENY sia deny, ma un URL in location, un ETag o un nonce dentro una Content-Security-Policy vengono confrontati esattamente come sono scritti.
No. Questa pagina riporta gli header di risposta, perché la richiesta la fa il nostro server e non il tuo browser. Per leggere gli header che invia il tuo browser apri gli strumenti per sviluppatori, vai alla scheda Rete ed espandi gli header di richiesta, oppure usa un servizio che restituisce l'eco della richiesta. Tutto ciò che vedi qui — lo stato, il punteggio e la tabella — descrive il sito che hai digitato, non il tuo client.