Cabecalhos de seguranca HTTP que importam: CSP, HSTS, X-Content-Type-Options, X-Frame-Options e Referrer-Policy explicados
Por que os cabeçalhos de resposta HTTP importam para segurança
Cada resposta HTTP carrega cabeçalhos — linhas de metadados enviadas antes do corpo que controlam como o navegador lida com o conteúdo. A maioria dos cabeçalhos é comum (Content-Type, Cache-Control), mas um conjunto específico de cabeçalhos de segurança instrui o navegador a aplicar restrições que bloqueiam categorias inteiras de ataques. Não são medidas teóricas de endurecimento; são defesas práticas contra classes de ataques que aparecem repetidamente no Top 10 do OWASP e nos bancos de dados CVE. Configurá-los não custa nada em desempenho — eles adicionam aproximadamente 200–400 bytes a cada resposta — e ferramentas como securityheaders.com atribuem uma nota a qualquer URL pública para que você possa ver imediatamente quais cabeçalhos estão faltando.
A ideia central é que cabeçalhos de segurança são aplicados pelo navegador, não pelo servidor. O servidor anuncia uma política; o navegador a aplica. Isso significa que uma configuração incorreta de cabeçalhos em um site de alto tráfego afeta simultaneamente o navegador de cada visitante. Por outro lado, adicionar os cabeçalhos corretos corrige anos de risco acumulado em uma única implantação. Os cinco cabeçalhos cobertos aqui — CSP, HSTS, X-Content-Type-Options, X-Frame-Options e Referrer-Policy — cada um tem como alvo um comportamento diferente do navegador que os invasores podem explorar.
Content-Security-Policy: o firewall contra XSS
O Cross-Site Scripting (XSS) é a vulnerabilidade web mais comum no Top 10 do OWASP. Um invasor que pode injetar uma tag <script> no seu HTML pode roubar cookies de sessão, redirecionar usuários ou exfiltrar dados de formulários. Content-Security-Policy (CSP) é um cabeçalho baseado em lista branca que diz ao navegador quais fontes são confiáveis para scripts, estilos, imagens, fontes e outros tipos de recursos. A diretiva Content-Security-Policy: default-src 'self' permite recursos apenas da mesma origem, bloqueando todos os scripts externos e blocos <script> inline. Uma diretiva script-src substitui o padrão especificamente para JavaScript.
A maior armadilha do CSP é a palavra-chave unsafe-inline. Adicionar script-src 'unsafe-inline' reativa scripts inline e derrota completamente a proteção XSS do CSP, mas é o recurso mais procurado quando um site quebra após habilitar o CSP. A alternativa correta são os nonces: cada carregamento de página gera um valor criptograficamente aleatório, incluído como script-src 'nonce-r4nd0m' no cabeçalho e como nonce="r4nd0m" em cada tag <script> legítima. Um script injetado sem o nonce correspondente é bloqueado mesmo que apareça inline. Para equipes que ainda não estão prontas para uma política estrita, Content-Security-Policy-Report-Only envia relatórios de violação para um endpoint coletor sem bloquear nada — uma forma segura de medir o impacto de uma política antes de aplicá-la.
HTTP Strict Transport Security: prevenindo ataques de downgrade HTTPS
O SSL stripping é um ataque de downgrade demonstrado publicamente na Black Hat 2009. Um invasor ativo no caminho intercepta a requisição HTTP inicial do usuário (antes de qualquer redirecionamento para HTTPS) e a encaminha como HTTP simples para a origem, enquanto serve a conexão criptografada de volta ao usuário. O usuário vê um cadeado em alguns navegadores, mas a conexão entre o invasor e o servidor é a não criptografada — credenciais e cookies de sessão são visíveis em texto simples. HTTP Strict Transport Security (HSTS) fecha essa janela instruindo os navegadores a recusar conexões HTTP para um domínio inteiramente, por um período definido pela diretiva max-age em segundos.
Um cabeçalho HSTS forte típico é Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. O max-age de 31536000 segundos é um ano — o mínimo necessário para inclusão na lista de pré-carregamento HSTS. includeSubDomains estende a política para cada subdomínio. preload sinaliza a intenção de ser incluído na lista de pré-carregamento fornecida pelo navegador em hstspreload.org; uma vez nessa lista, os navegadores recusarão conexões HTTP mesmo antes de terem visitado o site e recebido o cabeçalho. A restrição crítica: HSTS deve ser entregue via uma resposta HTTPS válida. Um cabeçalho enviado via HTTP é ignorado. Teste antes de implantar includeSubDomains — se algum subdomínio não tiver um certificado TLS válido, os usuários serão bloqueados durante todo o período max-age.
X-Content-Type-Options e X-Frame-Options: dois ganhos de segurança de valor único
O MIME sniffing é um comportamento legado onde alguns navegadores inspecionam os primeiros bytes de uma resposta para adivinhar seu tipo de conteúdo, substituindo o cabeçalho Content-Type. O Internet Explorer era o sniffer de MIME mais agressivo; ele executaria um .jpg como HTML se os primeiros bytes parecessem marcação. Um invasor que pode fazer upload de conteúdo para seu site (uma imagem, um arquivo de log) pode criar uma carga útil que é executada como script quando o navegador a fareja. X-Content-Type-Options: nosniff instrui todos os navegadores modernos a confiar no Content-Type declarado e ignorar o sniffing completamente. Tem exatamente um valor válido — nosniff — e não há razão para não defini-lo em cada resposta.
O clickjacking incorpora seu site dentro de um <iframe> em uma página controlada pelo invasor, depois sobrepõe botões transparentes para que os usuários cliquem involuntariamente em elementos da UI do seu site. X-Frame-Options: DENY impede que sua página seja enquadrada por qualquer um; X-Frame-Options: SAMEORIGIN permite o enquadramento apenas por páginas da mesma origem. A variante ALLOW-FROM uri está obsoleta e não é suportada nos navegadores atuais. O equivalente moderno é a diretiva CSP frame-ancestors (frame-ancestors 'none' mapeia para DENY, frame-ancestors 'self' mapeia para SAMEORIGIN), que adicionalmente suporta múltiplas origens permitidas. Como nem todos os navegadores verificam frame-ancestors em todos os contextos, definir tanto X-Frame-Options quanto uma diretiva CSP frame-ancestors fornece defesa em profundidade.
Referrer-Policy: controlando o vazamento de informações através do cabeçalho Referer
O cabeçalho HTTP Referer (escrito com um único 'r' devido a um erro tipográfico histórico no RFC) envia a URL completa da página da qual o usuário navegou para cada recurso externo que essa página carrega — imagens, scripts, folhas de estilo e destinos de cliques em links. Se um usuário logado visita /account/reset?token=eyJ... e essa página carrega um script de análise de terceiros, a solicitação do script carrega a URL completa incluindo o token de redefinição no cabeçalho Referer. O vazamento de tokens via referrer é uma classe de vulnerabilidade bem documentada; o GitHub corrigiu uma exposição de token baseada em referrer tão recentemente quanto 2020.
O cabeçalho Referrer-Policy substitui o mecanismo Meta referrer anterior e as soluções alternativas de supressão do cabeçalho Referer. A política strict-origin-when-cross-origin é o padrão recomendado: envia a URL completa para solicitações da mesma origem (útil para análises internas), mas apenas a origem simples (https://example.com) para solicitações de origem cruzada, e nada ao navegar de HTTPS para HTTP. no-referrer não envia nada, maximizando a privacidade mas quebrando qualquer análise que dependa do referrer. unsafe-url sempre envia a URL completa incluindo caminho e string de consulta — o padrão do navegador antes de 2020 e a fonte da maioria dos vazamentos históricos de referrer. Chrome, Firefox e Safari todos adotaram strict-origin-when-cross-origin como padrão em 2020–2021 quando nenhum cabeçalho de política está presente, mas defini-lo explicitamente garante comportamento consistente em todas as versões do navegador.
Uma linha de base de cabeçalhos de segurança prática para qualquer site
Para um site estático ou aplicação web simples, quatro cabeçalhos cobrem os vetores de ataque mais comuns com complexidade de configuração mínima: X-Content-Type-Options: nosniff (sempre, uma linha); X-Frame-Options: SAMEORIGIN (a menos que seu site precise ser incorporado legitimamente); Referrer-Policy: strict-origin-when-cross-origin; e Strict-Transport-Security: max-age=31536000; includeSubDomains (assim que confirmar que cada subdomínio é HTTPS). CSP requer mais planejamento — comece com Content-Security-Policy-Report-Only e um endpoint de relatório, colete violações por alguns dias, então escreva uma política que permita apenas o que você realmente usa.
A localização da configuração de cabeçalhos depende do seu stack: Nginx usa diretivas add_header no bloco do servidor; Apache usa Header always set em httpd.conf ou .htaccess; Vercel, Netlify e Cloudflare Pages cada um tem um arquivo de configuração de cabeçalhos ou configuração no painel. A maioria dos CDNs permite injeção de cabeçalhos na borda, o que é preferível a cabeçalhos no nível do aplicativo porque o CDN os entrega mesmo para respostas em cache. A ferramenta HTTP Headers Checker do TeaFun busca qualquer URL pública e exibe quais cabeçalhos de segurança estão presentes, seus valores e uma explicação de referência rápida do que cada um faz — use-a para auditar um site antes e depois de implantar alterações de cabeçalhos.