Análise de headers HTTP de segurança

Headers HTTP de segurança são instruções que o servidor envia com cada página para ativar proteções do navegador: obrigar o uso de HTTPS, limitar de onde vêm os scripts, impedir que o site seja embutido por outro e proteger os cookies. A ferramenta acima lê esses cabeçalhos em qualquer endereço público, dá uma nota de A+ a F e mostra o que corrigir.

Como usar

1. Digite o domínio (exemplo.com.br) ou a URL de uma página específica. Sem http:// ou https://, testamos a versão HTTPS.
2. A ferramenta segue até 5 redirecionamentos e mostra o caminho completo. A nota usa a última resposta, que é a página que o visitante realmente recebe.
3. Em cada item, veja o valor recebido, a sugestão de correção (com botão de copiar) e o link para a explicação nesta página.

Como a nota é calculada

A nota vai de 0 a 100 pontos. Cada proteção tem um peso e só pontua se estiver configurada de forma útil: presença sem efeito, como um HSTS com max-age=0, não conta.

As faixas são: A+ com 95 pontos ou mais e HSTS e CSP fortes, A a partir de 90, B a partir de 75, C a partir de 60, D a partir de 45 e F abaixo disso. Página entregue sem HTTPS recebe F direto. Cross-Origin-Resource-Policy, X-XSS-Protection e a exposição de versões aparecem como informativos, sem peso.

HTTPS vem antes de tudo

Sem HTTPS, qualquer intermediário (um Wi-Fi público mal-intencionado, por exemplo) pode ler e alterar a página, inclusive os próprios headers. Por isso o navegador ignora o HSTS recebido por HTTP. Antes de ajustar cabeçalhos, confira se o certificado é válido no verificador de certificado SSL e se o endereço com http:// redireciona para https://; a análise acima testa esse redirecionamento.

O que cada header faz

Strict-Transport-Security (HSTS)

Diz ao navegador para usar só HTTPS naquele domínio durante max-age segundos. Isso fecha a brecha do primeiro acesso digitado sem https://, que poderia ser interceptado em uma rede hostil, e impede que o visitante ignore um alerta de certificado. includeSubDomains estende a regra aos subdomínios. A diretiva preload pede a inclusão do domínio na lista embutida nos navegadores (hstspreload.org), que exige max-age de pelo menos um ano, includeSubDomains, preload e todos os subdomínios em HTTPS. Sair dessa lista leva meses, então só ative quando tiver certeza.

Content-Security-Policy (CSP)

A CSP é uma lista de origens permitidas para scripts, estilos, imagens e conexões. Se alguém conseguir injetar código na página (um ataque de XSS), o navegador recusa scripts que não estejam na política. Ela perde quase todo o efeito com 'unsafe-inline' sem nonce ou hash, ou com fontes amplas como https: e *. O caminho mais robusto é usar nonces ou hashes com 'strict-dynamic', mais object-src 'none' e base-uri. Comece com Content-Security-Policy-Report-Only, que só relata violações, até ter certeza de que nada legítimo será bloqueado.

frame-ancestors e X-Frame-Options (clickjacking)

No clickjacking, um site malicioso carrega o seu dentro de um iframe invisível e induz o visitante a clicar em botões reais sem perceber. A diretiva frame-ancestors da CSP define quem pode incorporar a página e, quando está presente, os navegadores atuais ignoram o antigo X-Frame-Options. Vale manter os dois: frame-ancestors 'self' e X-Frame-Options: SAMEORIGIN para navegadores antigos. O valor ALLOW-FROM é obsoleto, e frame-ancestors não funciona em CSP definida por <meta>.

X-Content-Type-Options

Com nosniff, o navegador deixa de adivinhar o tipo de um arquivo pelo conteúdo e respeita o Content-Type declarado. Isso evita que um arquivo enviado por usuário, como um texto ou imagem com código escondido, seja executado como script. É o único valor válido e quase nunca quebra nada.

Cookies: Secure, HttpOnly e SameSite

Secure impede o envio do cookie por HTTP. HttpOnly esconde o cookie do JavaScript, o que protege a sessão mesmo se houver XSS. SameSite controla o envio em requisições vindas de outros sites: Lax serve para a maioria dos casos, Strict é o mais restritivo e None exige Secure. Chrome e Edge tratam cookies sem SameSite como Lax, mas nem todo navegador faz isso, então declare sempre. O prefixo __Host- obriga Secure, Path=/ e nenhum Domain, o que impede subdomínios de sobrescrever o cookie. Para entender o lado do usuário, veja como cookies e fingerprinting rastreiam você.

Referrer-Policy

Controla quanto da URL de origem vai no cabeçalho Referer quando o visitante sai para outro site. Desde a revisão de 2020 da especificação, os navegadores usam por padrão strict-origin-when-cross-origin, que envia só o domínio para outros sites. O header serve para endurecer ainda mais (no-referrer, same-origin) ou para garantir o padrão em navegadores antigos. Os valores unsafe-url e no-referrer-when-downgrade enfraquecem a proteção e perdem pontos.

Permissions-Policy

Liga ou desliga recursos do aparelho para a página e para iframes de terceiros, como câmera, microfone e localização. Um valor como camera=(), microphone=(), geolocation=() desativa os três, mesmo que um script de anúncio ou de chat tente usá-los. Ele substituiu o antigo Feature-Policy, que tinha outra sintaxe.

Cross-Origin-Opener-Policy e Cross-Origin-Resource-Policy

O COOP separa a janela do seu site das janelas abertas por outros sites, o que bloqueia truques com window.opener e ataques de canal lateral. Use same-origin, ou same-origin-allow-popups se o site abre pop-ups de login ou pagamento de terceiros. O CORP diz quem pode embutir um recurso (imagem, script, resposta de API); ele faz mais diferença nesses arquivos do que na página HTML, por isso aparece aqui só como informativo.

Headers obsoletos

O X-XSS-Protection ativava um filtro de XSS que o Chrome removeu na versão 78, em 2019; o Firefox nunca o implementou. Como o filtro chegou a criar falhas próprias, a OWASP recomenda omitir o header ou enviar X-XSS-Protection: 0. Também não fazem mais sentido o Public-Key-Pins (HPKP) e o Expect-CT.

Server e X-Powered-By

Esses headers contam qual software e, às vezes, qual versão o servidor usa. Não são uma falha em si, mas facilitam a vida de quem procura sistemas desatualizados. Oculte as versões e remova o X-Powered-By; no PHP, desative expose_php.

Como configurar no seu servidor

Os exemplos abaixo trazem uma base segura. A CSP de exemplo só libera recursos do próprio domínio: se o site usa scripts de terceiros (analytics, anúncios, chat), adapte a lista e teste antes em modo Report-Only.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;
server_tokens off;

No Nginx, o always inclui os headers também em páginas de erro. Atenção: um add_header dentro de um bloco location faz esse bloco ignorar todos os add_header herdados do server, um motivo comum para páginas do mesmo site terem notas diferentes.

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set Cross-Origin-Opener-Policy "same-origin"
  Header unset X-Powered-By
</IfModule>

Em hospedagens compartilhadas com cPanel, o .htaccess costuma ser o único caminho. A diretiva ServerTokens Prod, que esconde a versão do Apache, só vale na configuração principal do servidor.

const securityHeaders = [
  { key: "Strict-Transport-Security", value: "max-age=31536000; includeSubDomains" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  { key: "Content-Security-Policy", value: "frame-ancestors 'self'; object-src 'none'; base-uri 'self'" },
];

export default {
  poweredByHeader: false,
  async headers() {
    return [{ source: "/(.*)", headers: securityHeaders }];
  },
};

Na Cloudflare e em outras CDNs, dá para adicionar cabeçalhos de resposta por regras no painel, sem mexer no servidor de origem. Se o servidor e a CDN enviarem o mesmo header, confira o resultado aqui: valores duplicados ou conflitantes são um erro frequente.

Problemas comuns

• O site respondeu 403 ou 503: firewalls e proteções anti-robô às vezes bloqueiam verificadores automáticos e devolvem uma página de desafio com outros headers. Teste outra página ou libere o verificador.
• A CSP quebrou o layout ou um script: abra o console do navegador (F12), veja qual recurso foi bloqueado e inclua a origem na diretiva certa. Use Report-Only enquanto ajusta.
• Nota diferente entre a página inicial e outras páginas: regras por pasta, blocos location ou aplicações diferentes atrás do mesmo domínio. Teste as páginas mais importantes, como login e checkout.
• Mudou o HSTS e nada aconteceu: o navegador guarda a regra até o max-age vencer. Para testar com calma, comece com um max-age curto e aumente depois.

Lembre que a nota avalia configuração, não reputação. Para saber se um endereço recebido por mensagem é confiável, veja como saber se um link é seguro. Para checar quem responde por um domínio e para onde ele aponta, use o Whois e o DNS Lookup.