Security Headers: o que cada um faz e como configurá-los

Resumo: Security headers são instruções que seu servidor envia junto com cada página, dizendo aos navegadores para sempre usar HTTPS, executar scripts apenas de fontes aprovadas por você, recusar que outros sites incorporem suas páginas em frames, nunca adivinhar tipos de arquivo e manter URLs completas fora do header Referer. Comece com HTTPS em todo o site e um certificado válido; depois adicione Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin e frame-ancestors ou X-Frame-Options. Implante o Content-Security-Policy primeiro em modo somente relatório (report-only). Todos são definidos na configuração do servidor ou da CDN.

Security headers são um seguro barato. A maioria exige uma linha de configuração no servidor, não custa nada em desempenho e fecha classes inteiras de ataques: um script injetado que rouba sessões, um frame invisível que induz pessoas a clicar, uma rede de cafeteria que rebaixa o visitante para HTTP simples. Também estão entre as primeiras coisas que scanners de segurança, clientes corporativos e questionários de segurança verificam.

Este guia explica cada header e os fundamentos de conexão ao redor deles, apresenta valores iniciais seguros, mostra como nosso verificador gratuito de security headers testa seu site e detalha a correção de cada problema que ele reporta.

Primeiro o básico: HTTPS, certificado e conteúdo misto

Os headers funcionam sobre uma conexão criptografada; sem ela, não ajudam. Três itens básicos vêm primeiro:

• HTTPS em todas as páginas, com redirecionamento do HTTP. Desde o Chrome 68, em julho de 2018, o Chrome marca toda página HTTP como "não seguro" (Chromium Blog), e as orientações de experiência da página do Google perguntam: "Are your pages served in a secure fashion?" (suas páginas são entregues de forma segura?)
• Um certificado válido que cubra todos os hostnames que você usa, incluindo www e o domínio sem prefixo. Um certificado expirado ou incompatível exibe um aviso em tela cheia.
• Sem conteúdo misto (mixed content). Uma página segura que carrega arquivos via http:// não é totalmente segura. Segundo a MDN, os navegadores atualizam imagens, áudio e vídeo para HTTPS automaticamente e bloqueiam de vez scripts, folhas de estilo, iframes e outros conteúdos "bloqueáveis", o que quebra a página.

Os headers, um por um

Strict-Transport-Security (HSTS)

O HSTS diz ao navegador para usar HTTPS no seu host por um número definido de segundos, mesmo quando alguém digita http:// ou clica em um link antigo. A MDN destaca três pontos:

• Os navegadores ignoram o header quando ele chega por HTTP simples. Envie-o nas respostas HTTPS; seu redirecionamento de HTTP para HTTPS não precisa dele.
• Só funciona depois da primeira visita segura. O preload fecha essa brecha.
• includeSubDomains aplica a política a todos os subdomínios, então verifique todos antes.

A lista de preload do HSTS fixa seu domínio diretamente nos navegadores. Ela exige um certificado válido, um redirecionamento de HTTP para HTTPS no mesmo host, todos os subdomínios em HTTPS e um header com max-age de pelo menos 31536000, includeSubDomains e preload. Ela também avisa que "inclusion in the preload list cannot easily be undone" (a inclusão na lista de preload não pode ser desfeita com facilidade): a remoção leva meses para chegar aos usuários. Faça o preload somente quando tiver certeza.

Content-Security-Policy (CSP)

O CSP é o mais forte dos headers e o mais difícil de implantar. Ele lista de onde scripts, estilos, imagens e outros recursos podem ser carregados, e o navegador recusa todo o resto. A MDN o descreve principalmente como "a defense against cross-site scripting (XSS) attacks" (uma defesa contra ataques de cross-site scripting).

A forma moderna recomendada é uma CSP estrita baseada em nonces ou hashes, em vez de longas listas de domínios permitidos:

Content-Security-Policy: script-src 'nonce-{RANDOM}'; object-src 'none'; base-uri 'none'

O nonce deve ser aleatório e diferente a cada resposta. A MDN alerta que 'unsafe-inline' "defeats much of the purpose of having a CSP" (anula boa parte do propósito de ter uma CSP).

Como uma política estrita pode quebrar tags de analytics, widgets de chat e scripts inline, implante em duas etapas: envie Content-Security-Policy-Report-Only com um endpoint de relatórios, corrija o que os relatórios mostrarem e só então passe para o header que aplica a política. É também no CSP que vive o upgrade-insecure-requests (uma rede de segurança contra conteúdo misto, não um substituto do HSTS) e onde o frame-ancestors controla a incorporação em frames.

X-Frame-Options e frame-ancestors

O clickjacking carrega sua página em um frame invisível em outro site e induz pessoas a clicar nos seus botões. Duas formas de impedir:

• X-Frame-Options: SAMEORIGIN (ou DENY), o header mais antigo. ALLOW-FROM está obsoleto e faz os navegadores modernos ignorarem o header.
• Content-Security-Policy: frame-ancestors 'self', a opção mais flexível, que também pode listar origens específicas de parceiros.

Nenhum dos dois funciona em uma tag <meta>. A MDN afirma que o X-Frame-Options em um elemento meta "has no effect" (não tem efeito) e que o frame-ancestors "is not supported in the <meta> element" (não é suportado no elemento <meta>). Observe também que o frame-ancestors não recorre ao default-src: uma política com default-src 'none' ainda permite que qualquer um incorpore a página em um frame.

X-Content-Type-Options

O nosniff diz aos navegadores para confiar no seu header Content-Type. Com ele, uma resposta solicitada como script ou folha de estilo é bloqueada se o tipo MIME não corresponder, o que impede que um arquivo enviado e disfarçado de imagem seja executado como script. Ele tem apenas um valor válido:

X-Content-Type-Options: nosniff

Certifique-se de que seu servidor envia os content types corretos, especialmente para JavaScript e CSS, antes de adicioná-lo.

Referrer-Policy

Quando um visitante clica em um link para outro site, o navegador envia um header Referer. Os navegadores modernos já usam como padrão strict-origin-when-cross-origin, que envia apenas a origem (https://example.com/) entre sites e nada ao ir de HTTPS para HTTP (MDN). A OWASP ainda recomenda defini-lo explicitamente "rather than relying on browser defaults" (em vez de depender dos padrões do navegador). Evite unsafe-url, que envia URLs completas, inclusive qualquer token contido nelas, para qualquer destino.

Permissions-Policy e os headers que devem sair

O Permissions-Policy desativa recursos do navegador que você não usa, para que um script incorporado não possa pedir acesso à câmera ou à localização. A MDN o classifica como experimental, com suporte limitado nos navegadores, então trate-o como uma camada extra. Nosso verificador gratuito não o testa; a varredura de segurança completa, sim.

Dois headers para remover em vez de adicionar: a OWASP diz para não definir o X-XSS-Protection (ou defini-lo como 0), porque os filtros antigos que ele controlava podiam criar vulnerabilidades, e considera o Expect-CT obsoleto. Ela também recomenda remover o X-Powered-By e dar ao Server um valor não informativo.

Como funciona o verificador de security headers da Searvia

O verificador de security headers gratuito usa o mesmo motor do nosso verificador de SEO de sites e coloca cinco verificações em primeiro lugar. Ele faz requisições comuns, que qualquer visitante poderia fazer; nada é atacado nem sondado.

Os três que ele conta são Content-Security-Policy, X-Frame-Options (ou um header CSP contendo frame-ancestors) e X-Content-Type-Options. O Referrer-Policy também é listado, mas a ausência dele não conta contra você: os navegadores já usam strict-origin-when-cross-origin como padrão, e a tabela informa isso. A tabela de resultados mostra o valor de cada um, com políticas longas abreviadas.

Alguns limites a ter em mente:

• Ele verifica a presença, não a qualidade. Uma CSP cheia de 'unsafe-inline' passa aqui; a varredura de segurança completa dá a nota disso.
• Ele lê os headers de resposta HTTP. Uma CSP definida em uma tag <meta> conta, com uma observação: frame-ancestors e relatórios não funcionam ali, então ela não substitui o X-Frame-Options. Um header Content-Security-Policy-Report-Only não conta como política aplicada.
• Ele verifica uma página, a que você informa (a home, se você informar só o domínio). Outros caminhos, como uma área administrativa ou uma API, podem enviar headers diferentes.
• O conteúdo misto é encontrado somente no HTML: URLs http:// absolutas em tags. Arquivos requisitados depois por CSS ou JavaScript não são vistos.

Como ler os resultados

Trabalhe de cima para baixo, por prioridade. Uma falha na verificação de HTTPS ou de certificado é urgente: os visitantes veem avisos do navegador ou trafegam sem criptografia. O conteúdo misto ativo (scripts, iframes, folhas de estilo) vem em seguida, porque os navegadores bloqueiam esses arquivos e a página pode quebrar. HSTS e os security headers têm prioridade baixa na pontuação, mas também são os mais rápidos de corrigir, então agrupe-os em uma única alteração de configuração.

Como corrigir cada problema reportado pelo verificador

"The site does not work over HTTPS." / "HTTP does not redirect to HTTPS."

1. Instale um certificado. O Let's Encrypt é gratuito e a maioria das hospedagens o oferece com um clique.
2. Adicione um redirecionamento permanente de cada URL http:// para a mesma URL https://.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Na Cloudflare, ative "Always Use HTTPS" em SSL/TLS › Edge Certificates.

"The certificate expired N days ago." / "The certificate does not cover this domain."

1. Renove-o agora e ative a renovação automática (o Certbot e a maioria das hospedagens e CDNs fazem isso por padrão).
2. Garanta que o certificado liste todos os hostnames que você atende, no mínimo o domínio sem prefixo e o www.
3. Se a renovação falhar em silêncio, as causas habituais são um registro DNS alterado, um caminho de validação bloqueado ou um token de API expirado para validação por DNS.

Um alerta com menos de 14 dias restantes normalmente significa que a renovação automática não está funcionando; investigue em vez de renovar manualmente toda vez.

"HSTS is not set." / "HSTS is on but shorter than 6 months."

Implante em etapas para que um subdomínio esquecido, só com HTTP, não fique inacessível:

1. Confirme que o site principal e todos os subdomínios funcionam em HTTPS.
2. Envie Strict-Transport-Security: max-age=300 por um dia, depois por uma semana (604800) e depois por um mês.
3. Passe para max-age=31536000; includeSubDomains.
4. Só então considere o preload e envie o domínio em hstspreload.org.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

"N files load over plain HTTP."

1. Abra a lista de URLs no relatório.
2. Mude cada uma para https:// ou para um caminho relativo, no caso de arquivos próprios. Para arquivos de terceiros, verifique se o provedor serve HTTPS; se não, troque de provedor.
3. Procure no banco de dados e no tema links http:// fixos no código; depois de uma migração para HTTPS, o conteúdo antigo de posts costuma ser a origem.
4. Como rede de segurança, adicione Content-Security-Policy: upgrade-insecure-requests.

"N key security headers are missing."

Adicione os que faltam em uma única alteração. Para nginx:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'self'; report-to csp" always;

Para Apache:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

Na Cloudflare, adicione headers de resposta com uma Transform Rule. Na Netlify, use um arquivo _headers; na Vercel, a configuração headers no vercel.json. No nginx, lembre que o add_header dentro de um bloco location substitui os headers definidos no nível do server, então repita-os ou use um arquivo de include.

Para o CSP, a linha report-only acima é um ponto de partida, não uma política pronta. Aponte o report-to para um endpoint de relatórios que você controle, revise as violações por uma ou duas semanas, ajuste a política e depois renomeie o header para Content-Security-Policy. Depois de aplicada, a verificação de CSP passa.

Como verificar os headers por conta própria

O verificador mostra o que a página verificada envia, mas outras páginas, arquivos e respostas de erro podem ser diferentes. Duas formas rápidas de conferir:

• DevTools do navegador. Abra o painel Network, recarregue a página, clique na primeira requisição e leia a seção Response Headers.
• Linha de comando. curl -sI https://www.example.com/ imprime apenas os headers de resposta. Execute para a home, uma página interna, um PDF, uma página 404 e sua página de login.

Uma surpresa comum são headers que aparecem nas páginas normais, mas não em erros ou redirecionamentos. No nginx, o add_header só se aplica a respostas de sucesso e de redirecionamento, a menos que você adicione o parâmetro always, e é por isso que todos os exemplos acima o incluem. Outra é uma CDN ou hospedagem que adiciona ou remove headers, então verifique a resposta que o público vê, não apenas o arquivo de configuração do servidor.

Lembre-se de que cada header protege uma coisa diferente. Uma CSP perfeita não faz nada por um certificado expirado, e o HSTS não faz nada contra um script injetado. O objetivo é o conjunto completo, adicionado em uma ordem sensata.

Exemplo prático (hipotético)

O exemplo a seguir é hipotético, não são dados reais. A Halden Legal, um escritório de advocacia inventado, recebe de um cliente corporativo um questionário de segurança que pergunta sobre os headers do seu site. O verificador de security headers reporta:

• HTTPS, certificado TLS: aprovado, 61 dias restantes.
• HSTS: alerta, max-age=86400 (um dia).
• Conteúdo misto: alerta, 2 imagens carregam via HTTP (um selo de parceiro e uma foto antiga da equipe).
• Security headers: 2 headers principais ausentes; apenas o X-Content-Type-Options está definido, e o Referrer-Policy mostra o padrão do navegador.

As correções levam uma tarde. As URLs das duas imagens são trocadas para HTTPS. Depois de confirmar que o subdomínio do portal do cliente funciona em HTTPS, o HSTS passa para max-age=31536000; includeSubDomains em duas etapas ao longo de uma semana. X-Frame-Options: SAMEORIGIN e Referrer-Policy: strict-origin-when-cross-origin são adicionados no servidor. Uma CSP em modo report-only roda por dez dias e revela um script inline do widget de agendamento, que é movido para um arquivo e permitido pela origem antes de a política ser aplicada. A execução final passa em todas as verificações, e o escritório responde ao questionário com um link para o relatório compartilhado.

Um checklist de uma hora

1. Execute o verificador de security headers e corrija primeiro as falhas de HTTPS e de certificado.
2. Remova o conteúdo misto listado no relatório.
3. Adicione X-Content-Type-Options, Referrer-Policy e X-Frame-Options ou frame-ancestors.
4. Aumente o HSTS por etapas até um ano, quando todos os subdomínios funcionarem em HTTPS.
5. Inicie uma CSP em modo report-only e agende uma revisão.
6. Remova o X-Powered-By, os números de versão no Server e qualquer X-XSS-Protection diferente de 0.

Como a Searvia continua monitorando a segurança do seu site

O verificador de security headers gratuito analisa sua home, ou qualquer página que você informar, em cerca de 20 segundos, sem cadastro, e o mesmo relatório cobre outras 33 verificações sobre aparência na busca, rastreamento, velocidade, mobile e autenticação de e-mail.

Uma conta gratuita da Searvia adiciona uma varredura de segurança semanal: verificações passivas de criptografia, proteções do navegador, flags de cookies, versões de software e proteção contra falsificação de e-mail, com a requisição e a resposta que comprovam cada achado. Ela dá nota à sua CSP (por exemplo, 'unsafe-inline' sem nonces ou hashes), verifica o Permissions-Policy e, depois que você verifica a propriedade, também procura arquivos .env e .git expostos, backups públicos, páginas de debug e CORS inseguro. Write the remediation plan with AI transforma os achados em configuração que você pode colar (5 créditos). Nos planos pagos a partir do Starter, o monitoramento de uptime também verifica seu certificado TLS diariamente e avisa antes de ele expirar.