Verificador de Cabeçalhos HTTP
Inspecione cabeçalhos HTTP e postura de segurança de qualquer URL.
🌐 sitekits fetches the URL server-side (private/internal addresses are blocked). Response body is not retrieved.
Visão geral
Os cabeçalhos de resposta são onde a maior parte do comportamento de um site está de fato configurada — cache, compressão, política de segurança, CORS, redirecionamentos — e são justamente a parte que você não consegue ver no navegador sem abrir o DevTools na requisição certa.
Esta ferramenta requisita uma URL do lado do servidor e devolve os cabeçalhos de resposta, mais a cadeia completa de redirecionamentos que levou até lá. Como o próprio modelo de segurança do navegador esconde do JavaScript os cabeçalhos de resposta de outra origem, esta é uma das poucas ferramentas daqui que não podem rodar inteiramente na sua página.
Como usar
- Digite uma URL. O esquema é opcional —
example.comé tratado comohttps://example.com. - Leia a cadeia de redirecionamento primeiro. Cada salto mostra a URL e o código de status.
- Leia os cabeçalhos da resposta final.
As cadeias de redirecionamento normalmente são a resposta
Quando algo está lento ou uma URL canônica está errada, é na cadeia que isso aparece. Cada salto é uma ida e volta completa, e os padrões mais comuns são todos evitáveis:
http://example.com→https://example.com→https://www.example.comsão dois redirecionamentos onde um bastaria. Redirecione direto para o host e o esquema finais em um único salto.- Um
301que cai em outro301depois de uma migração de site significa que duas gerações de regras continuam ativas ao mesmo tempo. - Um redirecionamento para uma URL que redireciona de volta é um laço; a ferramenta para depois de cinco saltos em vez de segui-lo.
- Um
302onde você queria um301diz aos rastreadores que a mudança é temporária, então a URL antiga mantém o ranking dela e a nova não acumula nada.
A distinção entre 301/302 e 307/308 é o método da requisição.
Historicamente os clientes transformavam um POST em GET ao seguir 301 e
302; 307 e 308 preservam o método. Se um envio de formulário se comporta de
forma estranha atrás de um redirecionamento, é a primeira coisa a verificar.
Cabeçalhos que valem uma leitura atenta
| Cabeçalho | O que observar |
|---|---|
cache-control | no-store em um ativo estático desperdiça banda; um max-age longo no HTML deixa os deploys invisíveis |
etag / last-modified | A ausência significa que cada revalidação transfere o corpo inteiro de novo |
content-encoding | A falta de gzip ou br em respostas de texto é o ganho de desempenho mais barato disponível |
vary | Vary: User-Agent fragmenta todo cache de CDN em centenas de cópias |
strict-transport-security | Um max-age curto, ou a falta de includeSubDomains, deixa a primeira requisição rebaixável |
content-security-policy | Veja o gerador de CSP para entender o que as diretivas significam |
x-content-type-options | Sem nosniff, um content-type digitado errado pode ser reinterpretado como script |
access-control-allow-origin | O motivo do seu fetch falhar está quase sempre aqui, ou na ausência dele |
set-cookie | Confira Secure, HttpOnly e SameSite em qualquer coisa que carregue sessão |
server e x-powered-by merecem atenção pelo motivo oposto: eles divulgam
versões de software e nada mais. Removê-los não é um controle de segurança, mas
não existe argumento para mantê-los.
O que a ferramenta deliberadamente não faz
O handler valida a URL contra uma lista de bloqueio de faixas de endereços
privados, de loopback, link-local e reservados antes de conectar, e repete essa
checagem em cada salto de redirecionamento. Sem a checagem por salto, um hostname
público poderia redirecionar para 127.0.0.1 ou para um endereço de metadados de
nuvem e a requisição seguiria — que é exatamente como um serviço de verificação de
cabeçalhos se torna um jeito de sondar a rede interna de outra pessoa de fora.
Ele também nunca repassa o corpo da resposta. A conexão é lida em busca dos cabeçalhos e depois descartada. Um serviço que devolve corpos arbitrários é um proxy aberto, independentemente de essa ter sido a intenção.
Credenciais embutidas em uma URL (https://user:pass@host/) são removidas antes
de a requisição ser feita, de modo que não são enviadas ao destino nem devolvidas
na cadeia de redirecionamento.
Exemplos
- Um erro de CORS que você não consegue reproduzir. Compare o
access-control-allow-origindo endpoint real com o que o seu código espera. Um cabeçalho ausente e um cabeçalho errado produzem a mesma mensagem no navegador. - Um deploy que não aparece. Olhe
cache-controleageno HTML. Um CDN servindo um documento em cache explica isso mais vezes do que o build. - Auditar o rollout de cabeçalhos de segurança. Confira
strict-transport-security,content-security-policyex-content-type-optionsno host em produção, e não na sua configuração, porque um CDN ou um WAF pode adicionar, remover ou sobrescrever qualquer um deles. - Verificar um redirecionamento canônico. Confirme que a cadeia termina em exatamente um salto, no host e no esquema que você pretende.
Observações
As requisições usam um User-Agent fixo que identifica esta ferramenta e expiram
depois de cinco segundos. Um site que bloqueia agentes desconhecidos vai
responder com um 403, o que é uma resposta real sobre a configuração daquele
site, e não uma falha daqui.
Os nomes dos cabeçalhos são exibidos como o servidor os enviou. O HTTP/2 exige
nomes em minúsculas na rede, então uma resposta por HTTP/2 vai mostrar
content-type onde uma resposta HTTP/1.1 poderia mostrar Content-Type. Os
nomes não distinguem maiúsculas de minúsculas em nenhum dos casos.
Se você precisa enviar cabeçalhos personalizados, um método específico ou um corpo de requisição, use o testador de REST API — ele roda do seu próprio navegador e por isso pode fazer coisas que um serviço compartilhado não deve.