Tema

Ferramentas populares

Verificador de headers HTTP

Verifique os headers HTTP de qualquer site: os headers de resposta exatamente como o servidor os enviou, em ordem e com os duplicados, com uma nota de segurança pelos testes do Mozilla HTTP Observatory, além de cache, cookies, servidor e protocolo.

Uma requisição do nosso servidor, o cabeçalho bruto mantido em ordem · testes publicados do Mozilla HTTP Observatory (algoritmo 6) · valores de cookies nunca mostrados nem guardados

Seguimos os redirecionamentos até a página final e avaliamos essa página. Os cabeçalhos de cada salto ficam em Redirecionamentos.

Como
Teste

O que são headers HTTP?

Headers HTTP são as linhas que um servidor envia antes da própria página: uma linha de status, depois um campo nome: valor por linha, depois uma linha vazia e o corpo (RFC 9110). Os nomes não diferenciam maiúsculas de minúsculas; os valores são do próprio servidor.

Os headers de resposta dizem ao navegador o que é o conteúdo, por quanto tempo ele pode guardar uma cópia, quais cookies armazenar e quais regras de segurança aplicar. Este verificador os mostra exatamente como enviados, em ordem e com todos os duplicados, e colore cada linha pelo que ela faz.

A anatomia de uma respostagithub.com · gravado em 24 de outubro de 2026
linha de statusHTTP/1.1200OK
linhas de campoStrict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-Frame-Options: deny
Cache-Control: max-age=0, private, must-revalidate
Content-Type: text/html; charset=utf-8
Set-Cookie: _gh_sess=‹344 caracteres›; path=/; HttpOnly; secure; SameSite=Lax
Server: github.com
… mais 14 linhas
corpo<!DOCTYPE html><html lang="en" …
Segurançao que o navegador deve aplicar
Cachepor quanto tempo uma cópia pode ser reutilizada
Cookieso que o navegador armazena
Servidor e bordaquem respondeu, por qual CDN

Como verificar os headers HTTP de um site?

Digite a URL acima e selecione Verificar headers: o verificador a requisita do nosso servidor, segue qualquer redirecionamento até a página final e mostra o cabeçalho de resposta dessa página linha a linha, com a nota de segurança ao lado. Escolha HEAD na caixa de método para pedir só o cabeçalho.

Selecione qualquer linha para ver o que ela faz e o que seu valor significa. As visões abaixo organizam os resultados: Segurança com a correção por servidor, Cache, Cookies, Servidor e protocolo e Redirecionamentos.

Verificador de headers: a resposta exatamente como enviada

Maiúsculas e ordem originais, duplicados mantidos, lido por HTTP/1.1; valores longos são quebrados, valores de cookies nunca aparecem. Um site atrás da Cloudflare é lido pela rede da Cloudflare, e o resultado informa isso.

Verifique os headers de segurança com os testes do Mozilla Observatory

Os mesmos 12 testes e pontos do código do Observatory, as duas rodadas calculadas na coluna de pontuação e um link para a análise do próprio Mozilla do host.

Verificador do header Server: software, CDN e protocolo

Server e X-Powered-By com qualquer versão que revelem, a CDN e seu status de cache, a versão do TLS, HTTP/2 e HTTP/3.

Verificador de HSTS e prontidão para preload

max-age, includeSubDomains e preload lidos contra as regras do hstspreload.org, como informação: o preload é opcional.

Verificação de headers HTTP do github.com: os headers de resposta como enviados e uma nota de segurança A+ de 115 pontosVerificação de headers HTTP do github.com: os headers de resposta como enviados e uma nota de segurança A+ de 115 pontosA nota e o vereditoA nota e os pontos do Observatory para a página final, com as correções que mais valem primeiro.Uma linha de header, como enviadaCada linha com as maiúsculas e a ordem do próprio servidor; a marca na margem é o resultado do teste desse header.A rodada de bônusOs bônus só contam quando a pontuação ainda é 90 ou mais depois de todas as penalidades: as duas rodadas do Observatory.As visõesSegurança com a correção por servidor, depois cache, cookies, servidor e protocolo, e os redirecionamentos.
Uma verificação de headers do github.com: a nota e o veredito, a resposta exatamente como enviada e as duas rodadas do Mozilla HTTP Observatory calculadas. Selecione um número para ver o que cada parte mostra.

Quais headers de segurança todo site deve enviar?

Comece por quatro: Content-Security-Policy, Strict-Transport-Security, proteção contra enquadramento (X-Frame-Options ou o frame-ancestors do CSP) e X-Content-Type-Options: nosniff. A falta deles custa mais pontos na nota do Mozilla HTTP Observatory.

Referrer-Policy e as políticas de origem cruzada (COOP, COEP e CORP) rendem pontos de bônus quando o básico está certo. Vale configurar o Permissions-Policy, mas só os navegadores Chromium o leem, e o Observatory não o pontua.

Os headers de segurança e quanto vale cada umMozilla HTTP Observatory · algoritmo 6
HeaderImpedeAusenteBem configuradoFunciona em
Content-Security-Policyscripts injetados−25+5 / +10
Strict-Transport-Securityum downgrade para http://−20+5 em preload
X-Frame-Options · frame-ancestorsclickjacking em um frame oculto−20+5
X-Content-Type-Optionsarquivos executados com o tipo errado−50
Referrer-PolicyURLs completas vazando para outros sites0+5
Cross-Origin-Opener-Policyoutras janelas acessando a sua0+10
Cross-Origin-Embedder-Policycarregar o que não aceitou0+10
Cross-Origin-Resource-Policyoutros sites incorporando seus arquivos0+10
Permissions-Policyembeds usando câmera, microfone, localização—não pontuadosó
Os bônus só contam quando a pontuação ainda é 90 ou mais depois das penalidades. Os outros testes do Observatory olham cookies, subresource integrity, CORS e o redirecionamento para HTTPS.

Como a nota de segurança é calculada?

Seguimos o método do Mozilla HTTP Observatory teste a teste: começar em 100, subtrair cada penalidade e, só se o resultado ainda for 90 ou mais, somar os bônus. A pontuação então vira uma nota de F a A+ (documentação de pontuação do Observatory).

Essa segunda rodada surpreende: um site com um erro caro não mantém nenhum dos seus bônus. Com COOP e COEP adicionados em 2026, o código do Observatory permite até 165 pontos, enquanto a documentação ainda dizia 145 em 24 de outubro de 2026; seguimos o código. Cada resultado leva à análise do próprio Mozilla do host, para você comparar.

Dois sites, calculadosResultados do próprio Observatory, 24 de outubro de 2026

github.comA+

  1. Início100
  2. Sem SRI em scripts externos−595
  3. 90 ou mais: a rodada de bônus conta
  4. Cookies: Secure, HttpOnly, SameSite+5
  5. Referrer-Policy+5
  6. HSTS em preload+5
  7. Enquadramento via CSP+5
  8. Pontuação115

www.mozilla.orgB+

  1. Início100
  2. O CSP permite 'unsafe-inline'−2080
  3. abaixo de 90: a rodada de bônus é ignorada
  4. COOP com same-origin+10
  5. Referrer-Policy+5
  6. Enquadramento via CSP+5
  7. Pontuação80
O site do Mozilla perde 20 pontos por uma diretiva do CSP, e então os 20 pontos de bônus que já havia ganhado não contam. Sem 'unsafe-inline' e 'unsafe-eval' nesse script-src, os mesmos headers somariam 120.

O que é HSTS, e você deve fazer o preload?

O Strict-Transport-Security diz aos navegadores para usar só https:// em um host por max-age segundos, e includeSubDomains estende isso a todos os subdomínios (RFC 6797). Os navegadores o ignoram em http:// puro, e só o primeiro header desse tipo conta. O Observatory tira 20 pontos quando ele falta e 10 quando o max-age é menor que seis meses.

O preload é opcional: o hstspreload.org agora diz que o HSTS é recomendado, mas o preload não, porque Chrome e Safari já atualizam as navegações para HTTPS e sair da lista leva meses. Para enviar mesmo assim, você precisa de um max-age de pelo menos um ano, includeSubDomains, preload e HTTPS em todos os subdomínios; aumente o max-age em etapas antes.

Dois domínios contra as regras do hstspreload.orggravado em 24 de outubro de 2026 · para informação

github.comna lista de preload

  • Certificado válido
  • http:// para https:// primeiro no mesmo hosthttp://github.com → https://github.com/
  • www também em HTTPS
  • max-age de 31536000 ou maismax-age=31536000
  • diretiva includeSubDomains
  • diretiva preload
  • HSTS também no seu redirecionamento para https://

mozilla.orgfora da lista

  • Certificado válido
  • http:// para https:// primeiro no mesmo host302 → https://mozilla.org:443/
  • www também em HTTPS
  • max-age de 31536000 ou maismax-age=60
  • diretiva includeSubDomains
  • diretiva preload · não enviado
  • HSTS também no seu redirecionamento para https://

Aumentando o max-age, como o hstspreload.org sugere

  1. 3005 min · para testar
  2. 6048007 dias
  3. 259200030 dias
  4. 31536000365 dias · o mínimo do preload

Nenhum dos resultados é uma falha: o hstspreload.org diz que o preload não é recomendado para a maioria dos sites, e o HSTS sem ele protege todo visitante depois da primeira visita.

O que faz um Content-Security-Policy?

Um Content-Security-Policy lista de onde uma página pode carregar scripts, estilos, imagens e frames, para que um script injetado por um invasor de qualquer outro lugar não seja executado. Sua diretiva frame-ancestors também diz quem pode enquadrar a página e substitui o X-Frame-Options (CSP Level 3).

'unsafe-inline' em script-src desfaz a maior parte dessa proteção, e por isso o Observatory tira 20 pontos por ele; use nonces ou hashes (com um deles na lista, os navegadores ignoram 'unsafe-inline'). Um header Content-Security-Policy-Report-Only não bloqueia nada, só relata, o que o torna a forma segura de testar uma nova política primeiro.

Um CSP, diretiva por diretivagithub.com e www.mozilla.org · 24 de outubro de 2026

github.com

default-srctudo que não está listado abaixo'none'
base-urio <base href> da página'self'
script-srcde onde os scripts podem carregargithub.githubassets.com 'sha256-6AKuI+cDd1MoUL1u4eqrA9PXmnPAkOB4h7421hPUUm0='
style-srcfolhas de estilo'unsafe-inline' github.githubassets.com
img-srcimagens'self' data: blob: github.githubassets.com media.githubusercontent.com camo.githubusercontent.com …
frame-ancestorsquem pode enquadrar esta página'none'
form-actionpara onde os formulários podem enviar'self' github.com gist.github.com copilot-workspace.githubnext.com …
script-src em www.mozilla.org'self' 'unsafe-eval' 'unsafe-inline' *.google-analytics.com *.googletagmanager.com google-analytics.com …
github.com parte de default-src 'none' e permite cada fonte pelo nome. Com um nonce ou um hash na lista, os navegadores ignoram 'unsafe-inline'; o Observatory então também não o conta.

Cache-Control explicado: por quanto tempo uma cópia pode ser reutilizada?

Pelo número de segundos que o seu max-age indica: o Cache-Control diz aos navegadores e às CDNs por quanto tempo podem reutilizar uma resposta sem consultar o servidor de novo, e o s-maxage define uma duração separada para caches compartilhados, como as CDNs (RFC 9111).

no-cache não significa "não guarde em cache": significa guarde, mas consulte o servidor antes de cada reutilização; no-store mantém a resposta fora de todo cache. O header Age diz quão velha já é a cópia de uma CDN, e sem nenhum Cache-Control um navegador pode estimar uma duração de cerca de 10% do tempo desde o Last-Modified.

Por quanto tempo uma cópia continua frescawww.wikipedia.org · gravado em 24 de outubro de 2026

Cache-Control: s-maxage=86400, must-revalidate, max-age=3600

Caches compartilhados (CDN)s-maxage=86400 · 24 hrestam 21 h e 39 min

Navegadoresmax-age=3600 · 1 hvencida

no-storenunca gravar em nenhum cache
no-cacheguardar, mas consultar o servidor antes de cada reutilização
max-age=Nfresca por N segundos (o Expires é então ignorado)
s-maxage=No mesmo, só para caches compartilhados
privatesó navegadores, nunca uma CDN
immutablenão revalidar ao recarregar (o Chrome ignora)
A cópia da CDN já tinha 2 h e 20 min quando chegou até nós, além dos 1 h dos navegadores: um navegador que a receba deve consultar o servidor (uma requisição ETag) antes de reutilizá-la.

Quais headers HTTP estão obsoletos?

X-XSS-Protection, Expect-CT, Public-Key-Pins, Feature-Policy e P3P não fazem mais nada útil nos navegadores atuais. O X-XSS-Protection deve ser 0 ou ausente, porque o antigo filtro podia abrir brechas por si só (OWASP).

Números de versão no Server e qualquer header X-Powered-By não estão obsoletos, mas a RFC 9110 e a OWASP desaconselham ambos: eles dizem aos invasores quais bugs conhecidos tentar (RFC 9110 §10.2.4).

Headers que você pode apagarOWASP · Chromium · RFC 9110
X-XSS-Protection: 1; mode=block

envie 0, ou nada

O Chrome 78 e o Safari 15.4 removeram seus filtros XSS; o Firefox nunca teve um. github.com e www.google.com enviam 0.

Chrome
Expect-CT

remova

Obsoleto desde o Chrome 107: o Certificate Transparency é exigido de qualquer forma.

Chrome
Public-Key-Pins

remova

Removido no Chrome 72; nenhum navegador atual o suporta.

Chrome
Feature-Policy

troque por Permissions-Policy

Renomeado: o header antigo está obsoleto.

Chrome
P3P

remova

Um padrão de privacidade morto que nenhum navegador atual lê; www.youtube.com ainda envia um.

YouTube
Server: Apache/2.4.62 (Ubuntu) X-Powered-By: PHP/8.3.12

tire a versão

Um exemplo fictício: a RFC 9110 e a OWASP dizem que esse detalhe só ajuda os invasores.

Apache

Como ver os headers HTTP no Chrome ou com curl?

No Chrome, abra o DevTools (F12), escolha Rede, recarregue, clique na primeira linha e abra Cabeçalhos. Com o curl, curl -sI https://example.com imprime o cabeçalho de resposta; acrescente --http1.1 para ver a grafia do próprio servidor.

Em HTTP/2 e HTTP/3 todo nome de header fica em minúsculas por regra (RFC 9113 §8.2.1), então o DevTools mostra strict-transport-security onde o servidor pode ter escrito Strict-Transport-Security. Este verificador lê por HTTP/1.1 e mantém o cabeçalho exatamente como enviado.

Veja os headers você mesmocurl · Chrome DevTools
$ curl -sI --http1.1 https://github.com
HTTP/1.1 200 OK
Date: Sat, 24 Oct 2026 08:19:43 GMT
Content-Type: text/html; charset=utf-8
Vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, X-Reques…
content-language: en-US
ETag: W/"6995be88733b84f6fb0c35e84ad1df53"
Cache-Control: max-age=0, private, must-revalidate
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-Frame-Options: deny
X-Content-Type-Options: nosniff
…
CabeçalhosVisualizaçãoRespostaTempo

DevTools › Rede › a linha do documento › Cabeçalhos. Marque Bruto para ver as linhas como recebidas. Em HTTP/2 todo nome chega em minúsculas; --http1.1 mostra a grafia do próprio servidor.

Verificador de headers HTTP: perguntas frequentes

Qual é uma boa nota de headers de segurança?

A ou A+ na escala do Mozilla HTTP Observatory: 90 pontos ou mais, para que a rodada de bônus conte. Um site sem nenhum header de segurança costuma ficar em D ou F; um que adiciona um CSP sem fontes inseguras, HSTS, proteção contra enquadramento e nosniff chega a 100, e Referrer-Policy, cookies e as políticas de origem cruzada o levam além de 100, até A+.

Por que minha nota é diferente da do securityheaders.com?

Eles medem coisas diferentes. O securityheaders.com avalia principalmente quais headers estão presentes, por um esquema de pontos que seu criador descreveu pela última vez em 2023. Nós seguimos os testes publicados do Mozilla HTTP Observatory, que também leem os valores, os cookies e o redirecionamento para HTTPS, e contam os bônus só a partir de 90. Cada resultado leva à análise do próprio Mozilla do host, para você comparar.

Os headers de segurança podem quebrar meu site?

Sim, dois deles podem. Um Content-Security-Policy rígido pode bloquear scripts ou estilos de que o site precisa, e o HSTS com includeSubDomains quebra qualquer subdomínio sem HTTPS. Lance um novo CSP primeiro como Content-Security-Policy-Report-Only, leia os relatórios e só então o aplique; aumente o max-age do HSTS em etapas, começando por cinco minutos, antes de se comprometer com um ano.

Posso verificar os headers HTTP com uma requisição HEAD?

Sim: escolha HEAD na caixa de método ao lado da URL. O servidor deve responder com os mesmos headers que enviaria para um GET, sem o corpo, embora alguns servidores ou CDNs respondam ao HEAD de forma diferente, e os testes que leem o HTML, como o subresource integrity, não têm página para ler. GET é o padrão porque mostra exatamente o que um navegador recebe.

O X-XSS-Protection ainda é necessário?

Não. Nenhum navegador atual tem o filtro XSS que ele controlava: o Chrome o removeu na versão 78, o Safari na 15.4, e o Firefox nunca teve um. A OWASP recomenda enviar X-XSS-Protection: 0 ou nada, porque o antigo filtro podia ser abusado, e o Mozilla Observatory abandonou seu teste em 2024. Hoje o que barra scripts injetados é um Content-Security-Policy.

O que faz o X-Content-Type-Options: nosniff?

Ele diz ao navegador para confiar no Content-Type que o servidor envia, em vez de adivinhar pelo conteúdo. Com nosniff, um script ou folha de estilo servido com o tipo errado é bloqueado, então um arquivo enviado por upload não pode ser executado como JavaScript. É o único valor válido, e o Observatory tira 5 pontos quando o header falta ou é inválido.

Por que os nomes dos headers aparecem em minúsculas no Chrome DevTools?

Porque a página veio por HTTP/2 ou HTTP/3, onde todo nome de header deve ficar em minúsculas (RFC 9113 §8.2.1). Os nomes de header não diferenciam maiúsculas de minúsculas, então nada está errado. Em HTTP/1.1 chega a grafia do próprio servidor, que é o que este verificador lê, então você pode ver Strict-Transport-Security aqui e strict-transport-security no DevTools para a mesma resposta.

Como adicionar headers de segurança no nginx ou na Cloudflare?

No nginx, adicione uma linha add_header por header no bloco server, com always para que as páginas de erro também os recebam, e recarregue. Na Cloudflare, use uma Response Header Transform Rule, ou um arquivo _headers no Pages. Depois verifique o site aqui: cada teste reprovado na visão Segurança vem com um trecho pronto para nginx, Apache, IIS, Cloudflare, Vercel, Netlify e Express.

O que é o header Server, e devo escondê-lo?

Ele nomeia o software que respondeu, como nginx ou cloudflare. Um nome de produto simples é inofensivo, mas a RFC 9110 alerta contra detalhes minuciosos e a OWASP recomenda reduzi-lo, porque um número de versão como Apache/2.4.62 diz aos invasores quais bugs conhecidos tentar. Remova o X-Powered-By por completo. A visão de header Server do verificador mostra o que os dois revelam.

O verificador de headers guarda os headers ou os cookies?

Não. Buscamos a URL do nosso servidor, mostramos o resultado e o mantemos por dois minutos para que um recarregamento ou um link compartilhado responda rápido; depois ele some. Os valores de cookies nunca são mostrados nem guardados: o verificador lista só o nome de cada cookie, o tamanho do seu valor e suas flags. Nada é ligado a você, e o site verificado nunca vê o seu endereço.

Sentiu falta de algo?Sugira um recurso ou uma nova ferramenta

Ferramentas de site relacionadas