O que são cabeçalhos de segurança? O que cada um faz e como adicioná-los

Cabeçalhos de segurança são cabeçalhos de resposta HTTP que mandam o navegador ativar proteções que ele já traz embutidas: conectar-se apenas por HTTPS, recusar scripts vindos de lugares inesperados, não deixar outros sites exibirem esta página em um frame, e assim por diante. Eles não consertam código vulnerável, mas tornam vários ataques comuns, como cross-site scripting, clickjacking e downgrade de protocolo, bem mais difíceis de executar ou menos danosos quando acontecem.

Como ver quais cabeçalhos o seu site envia

• No navegador: abra as ferramentas do desenvolvedor, vá até a aba Rede (Network), recarregue a página, clique na primeira requisição (a do documento) e veja os cabeçalhos de resposta (Response Headers).
• Pelo terminal: curl -I https://example.com exibe os cabeçalhos.
• Com um verificador: o verificador de segurança de site gratuito do Rudra confere se o site usa HTTPS e redireciona o HTTP simples para ele, se o certificado TLS é válido e não está prestes a expirar, e lê os valores de HSTS, Content-Security-Policy, X-Frame-Options (ou frame-ancestors da CSP), X-Content-Type-Options, Referrer-Policy e Permissions-Policy. Ele também sinaliza cabeçalhos Server ou X-Powered-By que revelam números de versão de software e verifica as flags dos cookies e o CORS.

A simples presença não é um veredito. Uma Content-Security-Policy que permite scripts de qualquer lugar está presente, mas protege muito pouco, e é por isso que o Rudra também interpreta os valores: um max-age de HSTS menor que 180 dias, uma CSP com 'unsafe-inline' ou * em script-src, ou um valor inválido de X-Frame-Options são reportados como fracos. Leia as seções abaixo para avaliar os seus próprios valores.

Os cabeçalhos, um a um

Strict-Transport-Security (HSTS)

Instrui o navegador a usar HTTPS no seu domínio por um período determinado, mesmo que alguém digite http:// ou siga um link antigo. Isso fecha a janela em que um invasor na rede poderia interceptar a primeira requisição insegura. Um valor comum é Strict-Transport-Security: max-age=63072000; includeSubDomains (dois anos).

• Comece com um max-age curto, como 300 segundos, e aumente quando tiver certeza de que todas as páginas funcionam em HTTPS.
• Adicione includeSubDomains somente se todos os subdomínios servirem HTTPS, inclusive os antigos de que você talvez nem se lembre.
• A flag preload, junto com o envio do domínio para a lista de preload dos navegadores, grava o HTTPS do seu domínio diretamente nos navegadores. Desfazer isso é difícil e demorado, então deixe-a por último e adicione de caso pensado.
• Os navegadores só respeitam o HSTS quando ele é recebido por HTTPS.

Content-Security-Policy (CSP)

Uma lista de onde a página pode carregar scripts, estilos, imagens, fontes e frames. Se um invasor conseguir injetar um script, uma boa CSP impede o navegador de executá-lo. É o cabeçalho mais poderoso desta lista e o mais fácil de errar. Um ponto de partida razoável para um site simples:

Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Essa política permite recursos apenas da sua própria origem (mais imagens embutidas via data:), bloqueia plugins, impede que tags <base> injetadas redirecionem URLs relativas e proíbe a exibição em frames. Sites reais usam analytics, fontes, conteúdos incorporados e provedores de pagamento, e cada um deles precisa ser liberado explicitamente; scripts inline ficam bloqueados, a menos que você os libere com um nonce ou um hash. Implante primeiro com Content-Security-Policy-Report-Only: o navegador reporta as violações no console (e a um endpoint de relatórios, se você configurar um) sem bloquear nada, e assim você ajusta a política antes de aplicá-la de verdade.

X-Content-Type-Options

X-Content-Type-Options: nosniff impede que os navegadores tentem adivinhar o tipo de um arquivo e, por exemplo, executem como script um arquivo de texto enviado por upload. Não tem configuração e raramente quebra alguma coisa, desde que o seu servidor envie cabeçalhos Content-Type corretos. Adicione em tudo.

Proteção contra clickjacking: frame-ancestors e X-Frame-Options

O clickjacking engana as pessoas para que cliquem em algo do seu site enquanto ele está escondido dentro de um frame de outro site. O controle moderno é a diretiva de CSP frame-ancestors 'none' (nunca permitir a exibição em frames) ou frame-ancestors 'self' (somente nas suas próprias páginas). Os mais antigos X-Frame-Options: DENY ou SAMEORIGIN fazem o mesmo trabalho em navegadores antigos, e enviar os dois não faz mal nenhum. Se as suas páginas precisam ser incorporadas em sites parceiros específicos, liste essas origens em frame-ancestors.

Referrer-Policy

Controla quanto da URL atual é enviado a outros sites quando os visitantes seguem um link ou carregam um recurso. URLs podem conter termos de busca, IDs ou tokens que você não quer vazar. Referrer-Policy: strict-origin-when-cross-origin envia a URL completa dentro do seu site, mas apenas a origem (https://example.com) para outros sites, e nada ao passar de HTTPS para HTTP. Os navegadores modernos já usam esse comportamento como padrão; defini-lo explicitamente garante consistência.

Permissions-Policy

Desativa recursos poderosos do navegador que o seu site não usa, de modo que nem o seu código nem um terceiro incorporado possam solicitá-los. Para um site que não precisa de câmera, microfone ou localização: Permissions-Policy: camera=(), microphone=(), geolocation=().

Cabeçalhos para remover ou deixar de lado

• Cabeçalhos que revelam versões. Valores de Server e X-Powered-By com números de versão dizem aos invasores exatamente qual software e qual versão atacar. Remova-os ou oculte a versão (no nginx, server_tokens off;).
• X-XSS-Protection controlava um filtro que os navegadores modernos já removeram. Não conte com ele; omita-o ou defina como 0.

Como adicionar cabeçalhos de segurança

nginx

• add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
• add_header X-Content-Type-Options "nosniff" always;
• add_header Referrer-Policy "strict-origin-when-cross-origin" always;
• add_header X-Frame-Options "DENY" always;

A flag always adiciona o cabeçalho também às respostas de erro. Cuidado com a herança: se um bloco location contiver qualquer diretiva add_header, ele deixa de herdar as definidas no nível server, e os cabeçalhos somem dessas URLs sem aviso. Repita-os ou mantenha-os em um arquivo compartilhado que você carrega com include.

Apache

Com o mod_headers habilitado, no virtual host ou no .htaccess: Header always set X-Content-Type-Options "nosniff", e o mesmo padrão para cada cabeçalho, como Header always set Referrer-Policy "strict-origin-when-cross-origin".

Next.js

No next.config.js, retorne os cabeçalhos para todos os caminhos: async headers() { return [{ source: '/:path*', headers: [{ key: 'X-Content-Type-Options', value: 'nosniff' }, { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' }] }]; }. Para uma CSP com nonces, gere o cabeçalho a cada requisição no middleware, como descreve a documentação do Next.js.

Netlify, Cloudflare Pages e hospedagens parecidas

Essas hospedagens leem um arquivo _headers na pasta publicada. Escreva um padrão de caminho em uma linha, como /*, e depois cada cabeçalho em sua própria linha indentada logo abaixo, como X-Content-Type-Options: nosniff. Na Vercel, o equivalente é a seção headers do vercel.json. Se você usa uma CDN, em geral ela também consegue adicionar cabeçalhos.

Implante com segurança

1. Adicione primeiro os cabeçalhos de baixo risco: X-Content-Type-Options, Referrer-Policy, Permissions-Policy e a proteção contra clickjacking.
2. Habilite o HSTS com um max-age curto e vá aumentando ao longo de algumas semanas.
3. Implante a CSP em modo report-only, corrija o que ela reportar e só então passe a aplicá-la.
4. Teste as jornadas que envolvem terceiros: login, checkout e frames de pagamento, vídeos incorporados, mapas, widgets de chat e analytics.
5. Confira de novo com o verificador de segurança, e repita sempre que adicionar uma nova ferramenta de terceiros.

Erros comuns

• Copiar uma CSP rígida de outro site e quebrar pagamentos, analytics ou conteúdos incorporados.
• Escrever uma CSP cheia de 'unsafe-inline', 'unsafe-eval' e curingas, que passa em um teste de presença mas protege pouco.
• Adicionar o preload do HSTS antes de todos os subdomínios estarem prontos para HTTPS.
• Definir cabeçalhos em uma tag <meta> do HTML. Só algumas diretivas de CSP funcionam assim; HSTS, frame-ancestors e X-Frame-Options são ignorados em meta tags.
• Adicionar cabeçalhos tanto na aplicação quanto no proxy, de modo que as respostas saem com valores duplicados ou conflitantes.
• Tratar os cabeçalhos como substitutos de atualizar o software, validar a entrada e escapar a saída.

O que os cabeçalhos e as verificações de cabeçalhos não cobrem

Os cabeçalhos são uma camada. Uma verificação de cabeçalhos não vai encontrar um plugin desatualizado, uma senha de administrador fraca, uma falha de injeção ou um arquivo de backup exposto. Os cookies também merecem uma revisão à parte: cookies de sessão devem ter os atributos Secure, HttpOnly e SameSite. O verificador de segurança do Rudra informa essas flags para os cookies definidos pela resposta da própria página (pelo nome, nunca pelo valor); veja como verificar a segurança dos cookies para os detalhes e como verificar a segurança de um site para saber o que uma verificação passiva consegue ou não dizer. Para uma visão mais ampla da saúde do seu site, faça uma auditoria de site completa.