Como verificar os headers de segurança de um site

Para verificar os cabeçalhos de segurança de um site, peça a página por HTTPS e confira seis headers de resposta: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options (ou frame-ancestors dentro da CSP), X-Content-Type-Options, Referrer-Policy e Permissions-Policy, além dos atributos de cada Set-Cookie. Um header ausente nem sempre é uma brecha, e um header presente não garante nada: o que importa é o valor. A nossa consulta de cabeçalhos HTTP grátis mostra todos os headers de uma URL em segundos, sem criar conta.

Todos os resultados deste guia vieram de testes reais feitos em 3 de novembro de 2026 com a nossa ferramenta no GitHub, na BBC e no example.com. As regras vêm do MDN, dos requisitos oficiais da lista de pré-carregamento HSTS e da RFC 6797, conferidos no mesmo dia.

Já tem a URL? Cole o endereço completo, com https://, na ferramenta gratuita de cabeçalhos HTTP e deixe o resultado aberto enquanto lê a lista abaixo.

Os seis headers que importam e o valor que eles deveriam ter

Um header que você já pode esquecer: X-XSS-Protection. O MDN avisa que ele pode criar vulnerabilidades XSS em sites que seriam seguros e recomenda usar Content-Security-Policy. Por isso o GitHub envia x-xss-protection: 0, desligando de propósito o filtro antigo.

Como verificar os headers de segurança passo a passo

1. Use a URL exata em que as pessoas chegam

Digite o endereço completo com o esquema: https://github.com/, não github.com. Quando testamos só o domínio, a ferramenta mostrou um aviso de campo obrigatório em vez do resultado, porque precisa do esquema para saber o que pedir. Confira a home, mas também login, formulários e checkout: muitas vezes são servidos por outra aplicação, com outros headers.

2. Faça a consulta

Abra a consulta de cabeçalhos HTTP, cole a URL e clique no botão. A requisição sai do nosso servidor, então você vê o mesmo que qualquer visitante recebe, sem extensões nem cache do seu navegador no meio. É grátis e não pede conta; sem cadastro você tem 5 consultas por dia, e uma conta gratuita (sem spam) remove esse limite.

3. Encontre o salto que interessa

A ferramenta segue os redirecionamentos e junta os headers de todos os saltos numa tabela só. A primeira linha mostra o status da primeira resposta. Ao consultar http://github.com, a tabela começou com HTTP/1.1 301 Moved Permanently e Location: https://github.com/, e tudo o que veio depois era da página HTTPS final. A regra: o que aparece abaixo da última linha Location é o que a página vista pelas pessoas envia. Para uma tabela limpa, consulte direto a URL HTTPS final e use o verificador de redirecionamentos para ver o código de cada salto.

4. Compare cada header com a tabela

Passe pelas seis linhas acima. Anote o que falta e depois leia o valor do que existe, porque um valor fraco é um problema mais comum do que um header ausente.

5. Confira os atributos dos cookies

Todas as linhas Set-Cookie aparecem juntas numa linha da tabela. Um cookie de sessão deve ter Secure, HttpOnly e um valor de SameSite. Um cookie de analytics pode ficar sem HttpOnly de propósito, porque os scripts precisam lê-lo.

Exemplo 1: GitHub, a referência forte

A consulta de https://github.com/ retornou HTTP/2 200 e estas linhas de segurança (CSP encurtada):

strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'; base-uri 'self'; child-src github.githubassets.com ...

• A CSP parte de default-src 'none': nada carrega se uma diretiva não permitir. É o ponto de partida mais rígido e o melhor para copiar num site novo.
• A Referrer-Policy é uma lista. O MDN documenta isso como política de reserva: o navegador aplica o último valor que entende, então os navegadores atuais usam strict-origin-when-cross-origin.
• Cada cookie tem os atributos certos para a sua função. _gh_sess e logged_in têm HttpOnly; secure; SameSite=Lax; _octo tem secure; SameSite=Lax sem HttpOnly, o que faz sentido para um valor lido por scripts.

Não há Permissions-Policy. Nem sites muito bem cuidados enviam tudo, então use a lista como guia, não como nota.

Exemplo 2: BBC, headers presentes mas fracos

A consulta de https://www.bbc.com/ mostrou:

referrer-policy: no-referrer-when-downgrade
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=31536000; preload

Numa olhada rápida, quatro de seis. Lendo com calma, aparecem dois problemas reais:

• A política de referrer é mais fraca que o padrão do próprio navegador. Segundo o MDN, sem política definida o navegador usa strict-origin-when-cross-origin, e no-referrer-when-downgrade era o padrão anterior. Ao fixar o valor antigo, o navegador envia a URL completa, com caminho e parâmetros, para qualquer outro site HTTPS; sem o header, enviaria só o domínio.
• Pede para entrar na lista de pré-carregamento HSTS, mas não se qualifica. O hstspreload.org exige includeSubDomains junto com preload e max-age de pelo menos um ano no domínio base. Testamos também https://bbc.com/: ele responde com 301 para o www e o mesmo max-age=31536000; preload, sem includeSubDomains.

Também não há Content-Security-Policy. Numa página com anúncios e muitos scripts de terceiros, essa é a maior lacuna e a mais difícil de fechar.

Exemplo 3: example.com, nada

https://example.com/ retornou HTTP/2 200 com data, tipo de conteúdo, server: cloudflare, linhas de cache e nenhum header de segurança. Pedido por http:// a partir do nosso servidor, respondeu HTTP/1.1 200 OK sem redirecionar para HTTPS. Num site real, seria a primeira coisa a corrigir; numa página estática de documentação, sem login, cookies ou formulários, o risco é baixo. Essa é a regra do contexto: faltar CSP numa página institucional não é o mesmo que faltar CSP no checkout de uma loja.

Armadilhas que deixam a verificação enganosa

• HSTS no redirecionamento HTTP não vale. O MDN e a RFC 6797 dizem que o navegador ignora Strict-Transport-Security recebido por HTTP sem criptografia. O salto http:// do GitHub envia só o 301 e o Location; o header chega com a página HTTPS, que é o correto.
• Um 302 de HTTP para HTTPS funciona, mas um 301 é mais limpo. http://www.bbc.com/ respondeu 302 Found e http://github.com/, 301. Os dois chegam ao HTTPS; é o HSTS que elimina essa primeira requisição insegura nas visitas seguintes. Explicamos a diferença no guia sobre como saber se um redirecionamento é 301 ou 302.
• Content-Security-Policy-Report-Only não bloqueia nada. Só relata: o site está testando uma política, não protegido por ela.
• A CDN pode adicionar ou remover headers. Se o seu servidor define um header e a consulta não mostra, confira as regras da CDN antes de culpar a aplicação.
• Meta tag não é header. Uma CSP definida com <meta http-equiv> não aparece nesta consulta e não aceita frame-ancestors. Para ver o que está no HTML, use o verificador de meta tags.
• Headers bons não provam que o site é confiável. Uma página de phishing pode enviar todos perfeitos. Para avaliar um site desconhecido, siga o nosso guia para saber se um site é confiável e confira o certificado com a consulta SSL.

Um ponto de partida sensato para o seu site

Para um site típico servido só por HTTPS, esta é uma primeira versão segura. Teste numa cópia de homologação e publique a CSP primeiro como Report-Only:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'

Adicione includeSubDomains só quando todos os subdomínios funcionarem em HTTPS, e não coloque preload até ter certeza, porque sair da lista de pré-carregamento é demorado. Depois passe a URL de novo pela consulta de cabeçalhos grátis e confirme que cada linha chegou exatamente como escrita.

Perguntas frequentes

Como verificar os headers de segurança de graça?

Cole a URL completa, com https://, na consulta de cabeçalhos HTTP do My Botsy. Ela lista todos os headers de resposta em segundos e sem conta. Você também pode rodar curl -sI seguido da URL num terminal, ou abrir as ferramentas de desenvolvedor do navegador, aba Rede, e clicar na requisição da página.

Quais headers de segurança todo site deveria ter?

Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options com nosniff, uma Referrer-Policy e proteção contra iframes com X-Frame-Options ou frame-ancestors. Permissions-Policy vale a pena se você incorpora conteúdo de terceiros. X-XSS-Protection está obsoleto: defina 0 ou não envie.

Por que a consulta mostra primeiro um 301?

Porque ela segue os redirecionamentos e junta todos os saltos numa tabela; a primeira linha é o status da primeira resposta. O que vem depois da última linha Location pertence à página final. Consulte direto a URL HTTPS final para um resultado limpo.

Um site sem Content-Security-Policy é inseguro?

Não necessariamente. A CSP limita o estrago se alguém conseguir injetar um script. Uma página estática sem login, formulários ou scripts de terceiros tem pouco a proteger; um login ou checkout sem CSP tem uma lacuna real.

Dá para adicionar headers de segurança sem acesso ao servidor?

Muitas vezes, sim. CDNs como a Cloudflare permitem adicionar headers de resposta por regras, e muitas hospedagens deixam definir no .htaccess ou no painel. A CSP também pode ir numa meta tag, mas frame-ancestors só funciona como header de verdade.

Headers de segurança ajudam no SEO?

A função deles é proteger os visitantes, não ranquear, então não espere um salto de tráfego. O que eles trazem é confiança e consistência: o HSTS mantém em HTTPS quem volta ao site, e um redirecionamento limpo de HTTP para HTTPS faz os buscadores verem uma só versão de cada página.