Vai al contenuto
IPeek

Verifica header HTTP

Esamina header di risposta, redirect e sicurezza

Verifica in corso…

Cosa sono gli header di risposta HTTP?

Gli header di risposta HTTP rivelano come si comporta un web server: il codice di stato che restituisce, dove reindirizza, quale software esegue e quali header di hardening di sicurezza invia. Header mancanti come HSTS, Content-Security-Policy o X-Frame-Options lasciano i siti esposti ad attacchi di downgrade, injection e clickjacking. IPeek segue l'intera catena di reindirizzamenti e valuta la risposta rispetto agli header di sicurezza chiave.

Come funzionano gli header HTTP e i codici di stato

Ogni risposta HTTP inizia con un codice di stato e un insieme di header prima del corpo della pagina. Il codice di stato indica al client cos'è successo: 200 significa successo, 301 e 302 significano che la risorsa è stata spostata, 404 significa non trovato e 5xx significa che il server ha fallito. Gli header trasportano metadati come Content-Type, Server, Cache-Control e le direttive di sicurezza che istruiscono il browser su come trattare la pagina. IPeek richiede l'URL, cattura questi header esattamente come li ha inviati il server e segue ogni reindirizzamento così vedi l'intero percorso fino alla risposta finale.

Come interpretare i risultati su header e reindirizzamenti

Per prima cosa conferma che il codice di stato finale sia quello atteso, tipicamente 200 per una pagina attiva. Poi percorri la catena di reindirizzamenti: una configurazione pulita reindirizza HTTP a HTTPS e qualsiasi host non canonico a quello canonico nel minor numero di hop possibile, perché ogni reindirizzamento in più aggiunge latenza. Fai attenzione ai loop di reindirizzamento o a una catena che approda sull'host sbagliato. L'header Server rivela il software in uso, e la valutazione degli header di sicurezza mostra a colpo d'occhio quali header protettivi sono presenti e quali mancano.

Header di sicurezza chiave e lacune comuni

Strict-Transport-Security (HSTS) costringe i browser a usare HTTPS, prevenendo gli attacchi di downgrade. Content-Security-Policy limita da dove possono caricarsi script e risorse, la difesa più forte contro il cross-site scripting. X-Frame-Options o la direttiva CSP frame-ancestors blocca il clickjacking controllando chi può incorporare la tua pagina. X-Content-Type-Options: nosniff ferma il MIME sniffing. La lacuna più comune è un sito che non serve nessuno di questi, lasciando il browser senza alcuna protezione aggiuntiva. Aggiungili a livello di web server o CDN, poi ricontrolla per confermare che compaiano nella risposta live.

Quando eseguire un controllo degli header HTTP

Controlla gli header dopo un deploy, dopo aver cambiato CDN o reverse proxy, e ogni volta che irrobustisci la postura di sicurezza di un sito, perché sono i momenti in cui gli header vengono aggiunti, eliminati o sovrascritti. È il modo più rapido per confermare che un reindirizzamento da HTTP a HTTPS funzioni davvero, per fare il debug di una catena di reindirizzamenti inattesa, o per verificare che un header di sicurezza configurato stia raggiungendo i browser reali invece di essere rimosso da qualche parte nel percorso di consegna.

Domande frequenti

Cosa rivela un controllo degli header HTTP?

Mostra il codice di stato, la catena di reindirizzamenti, il software del server e gli header di sicurezza che un sito restituisce. Vedi se l'URL reindirizza correttamente, quanti hop richiede, quale server risponde e quali header protettivi come HSTS e Content-Security-Policy sono presenti o mancanti. Questo lo rende una diagnosi rapida sia per problemi di instradamento sia per lacune di sicurezza.

Che cos'è HSTS e perché è importante?

HTTP Strict-Transport-Security è un header che indica ai browser di connettersi solo tramite HTTPS per un periodo definito. È importante perché previene attacchi di downgrade e man-in-the-middle in cui un aggressore forza una connessione HTTP non sicura. Una volta che un browser vede HSTS, rifiuta l'HTTP in chiaro verso quell'host finché la policy non scade, chiudendo una reale finestra di attacco.

Perché il mio sito ha così tanti reindirizzamenti?

Le catene di reindirizzamenti di solito si accumulano quando regole separate risolvono ciascuna una cosa: da HTTP a HTTPS, da non-www a www e la normalizzazione dello slash finale. Ogni hop aggiunge latenza e una possibilità di errore. Comprimile in un unico reindirizzamento verso l'URL canonico finale dove possibile, e fai attenzione ai loop in cui due regole si rimbalzano la richiesta avanti e indietro.

Quali header di sicurezza dovrebbe avere ogni sito?

Come minimo, invia Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff e la protezione dai frame tramite X-Frame-Options o CSP frame-ancestors. HSTS impone HTTPS, CSP limita l'injection di script, nosniff ferma la confusione MIME e la protezione dai frame blocca il clickjacking. Insieme coprono le classi di attacco lato browser più comuni con direttive che imposti una sola volta a livello di server o CDN.

Qual è la differenza tra un reindirizzamento 301 e 302?

Un 301 è un reindirizzamento permanente e un 302 è temporaneo. Un 301 indica a browser e motori di ricerca che la risorsa si è spostata definitivamente, quindi aggiornano i preferiti e trasferiscono i segnali di ranking al nuovo URL. Un 302 dice che lo spostamento è temporaneo, quindi i client continuano a usare l'URL originale. Usa 301 per i reindirizzamenti canonici e verso HTTPS.