Verificador de Cabeçalhos HTTP
Vê os cabeçalhos de resposta HTTP e a cadeia de redirecionamentos de qualquer URL, com uma auditoria dos cabeçalhos de segurança.
A carregar Verificador de Cabeçalhos HTTP… Se nada acontecer, ativa o JavaScript.
Cada resposta web começa com um bloco de cabeçalhos HTTP que o visitante nunca vê: o código de estado, para onde aponta um redirecionamento, durante quanto tempo a página pode ficar em cache, que tipo de conteúdo é e um conjunto de instruções de segurança para o navegador. A maioria dos problemas de SEO, desempenho e segurança deixa ali o primeiro rasto: um ciclo de redirecionamentos, um 302 que devia ser 301, um cabeçalho HSTS em falta, um CDN que se recusa a guardar em cache. Esta ferramenta pede um URL a partir do nosso servidor e mostra esses cabeçalhos tal como chegam.
Exemplos
http://github.com
301 → https://github.com/ → 200
Um redirecionamento de HTTP para HTTPS e depois a página final com HSTS, CSP e X-Frame-Options definidos.
Cache-Control: max-age=0, private, must-revalidate
Stored, but revalidated with the server on every use (browser only, not CDNs).
O resumo de cache traduz as diretivas para linguagem simples.
Perguntas frequentes
Qual é a diferença entre um redirecionamento 301 e um 302?
Quantos redirecionamentos são demasiados?
Que cabeçalhos de segurança são mais importantes?
Porque vejo cabeçalhos diferentes dos que aparecem nas ferramentas de programador do navegador?
Porque é que a ferramenta indica GET em vez de HEAD?
Posso verificar uma página em localhost ou na minha rede interna?
A ferramenta verifica o certificado TLS?
Os URL que verifico ficam guardados?
Sobre Verificador de Cabeçalhos HTTP
Cola um URL e o verificador faz o pedido como um navegador faria, sem seguir redirecionamentos automaticamente. Cada salto aparece por ordem com o código de estado, o tempo de resposta e a lista completa de cabeçalhos, para veres todo o caminho de http://example.com até ao https://www.example.com/ final e identificares saltos a mais que atrasam a primeira visita. Clica em qualquer salto para ver os cabeçalhos dele, filtra-os por nome ou valor e copia-os como texto simples.
A resposta final recebe uma auditoria dos cabeçalhos de segurança. A ferramenta verifica Strict-Transport-Security (e o seu max-age), Content-Security-Policy (e se ainda permite scripts unsafe-inline), X-Frame-Options ou frame-ancestors da CSP contra clickjacking, X-Content-Type-Options, Referrer-Policy, Permissions-Policy e Cross-Origin-Opener-Policy, e assinala cabeçalhos que revelam versões de software do servidor. Cada item explica em linguagem simples o que o cabeçalho faz e o que falta. Uma secção à parte traduz Cache-Control, Expires, ETag, Age e Vary numa resposta de uma linha sobre como a página é guardada em cache.
Os pedidos saem do nosso servidor, por isso vês a resposta pública e não o que o teu navegador ou um proxy local envia. Primeiro tenta-se um pedido HEAD e usa-se GET quando o servidor rejeita HEAD, parando assim que chegam os cabeçalhos, para que nenhum corpo de página seja descarregado. Só são permitidos http e https nas portas 80, 443, 8080 e 8443, cada destino de redirecionamento é verificado de novo e os endereços privados ou internos são bloqueados.
Cabeçalhos que sobreviveram ao seu propósito
Os cabeçalhos HTTP acumulam história. O cabeçalho Referer está mal escrito porque Phillip Hallam-Baker o escreveu com um só 'r' no rascunho dos anos 90, e quando alguém reparou já havia servidores por todo o lado a depender dele. O mais recente Referrer-Policy está escrito corretamente, por isso a web transporta agora as duas grafias lado a lado.
O X-XSS-Protection é um cabeçalho que acabou por ser desligado de propósito. O Internet Explorer 8 introduziu um filtro de XSS em 2008 e o Chrome seguiu-o, mas investigadores descobriram que o próprio filtro podia ser explorado para revelar dados ou desativar scripts legítimos. O Chrome removeu o seu XSS Auditor em 2019, e o valor recomendado hoje é 0, ou nenhum cabeçalho, ficando o trabalho a sério para a Content-Security-Policy.
O próprio prefixo X- foi oficialmente desaconselhado pelo RFC 6648 em 2012. A ideia era que os cabeçalhos experimentais levassem X- e o perdessem quando fossem normalizados, mas cabeçalhos populares como X-Forwarded-For e X-Frame-Options nunca perderam o prefixo, porque mudar-lhes o nome só iria partir coisas. Os cabeçalhos novos são agora registados sem ele desde o início.