5 cabeçalhos HTTP de segurança que seu site provavelmente não tem

Quando uma página carrega no navegador, o servidor manda — junto com o HTML — uma série de cabeçalhos HTTP invisíveis. Alguns desses cabeçalhos servem pra dizer ao navegador: "ei, não confia em qualquer coisa, eu vou te orientar sobre o que é seguro aqui."

Sem eles, o navegador opera no modo padrão, que é permissivo demais pro mundo moderno. Vamos a cinco que você consegue adicionar sem tocar no código da aplicação — só configuração de servidor ou middleware.

1. Strict-Transport-Security (HSTS)

Strict-Transport-Security: max-age=31536000; includeSubDomains

O que faz: diz ao navegador "use HTTPS pra esse domínio por X segundos". Mesmo se o usuário digitar http://seusite.com, o navegador vai automaticamente trocar pra https:// sem nem fazer o request inseguro.

Por que importa: sem HSTS, o primeiro acesso a um domínio acontece em HTTP (mesmo que redirecione pra HTTPS depois). Isso abre uma janela curta pra ataque SSL stripping em redes hostis.

Cuidado: max-age alto + includeSubDomains é compromisso pesado. Comece com 1 hora (3600), depois 1 dia, depois 1 ano. Se desativar HTTPS em algum subdomínio depois, vai quebrar.

2. Content-Security-Policy (CSP)

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; img-src 'self' data: https:;

O que faz: controla de onde o navegador pode carregar recursos (scripts, imagens, fontes). Bloqueia injeção de script de domínios não-autorizados.

Por que importa: é a defesa mais forte contra XSS (cross-site scripting). Mesmo se um atacante conseguir injetar <script> na sua página, o navegador recusa executar se o domínio não estiver autorizado.

Cuidado: CSP estrito quebra coisas — inline scripts, eval, fontes do Google. Comece permissivo ('unsafe-inline' em script-src) e vai endurecendo. Use o report-only primeiro: Content-Security-Policy-Report-Only: ... faz o navegador reportar violações sem bloquear.

3. X-Frame-Options

X-Frame-Options: DENY

O que faz: impede o seu site de ser carregado dentro de <iframe> em outras páginas.

Por que importa: sem isso, um atacante pode embed seu site num iframe transparente sobreposto a botões falsos — clickjacking. O usuário acha que está clicando em "OK aceito cookies" no site do atacante, mas está clicando em "Transferir R$ 1.000" no seu.

Alternativa moderna: Content-Security-Policy: frame-ancestors 'none' faz a mesma coisa com mais flexibilidade. Hoje você quer ambos — alguns navegadores mais antigos só leem X-Frame-Options.

4. X-Content-Type-Options

X-Content-Type-Options: nosniff

O que faz: impede o navegador de "adivinhar" o tipo de um arquivo. Se o servidor disse Content-Type: text/plain, o navegador trata como texto — não como script HTML, mesmo que o conteúdo pareça HTML.

Por que importa: sem nosniff, atacantes podem fazer upload de um arquivo .txt com conteúdo <script> e induzir o navegador a executar. Com nosniff, o navegador respeita o Content-Type declarado.

Cuidado: zero. Esse header não quebra nada. Se você ainda não tem, adicione agora.

5. Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

O que faz: controla quanta informação sobre a URL atual é enviada quando o usuário clica num link saindo do seu site.

Por que importa: sem essa policy, o Referer header vaza a URL completa — incluindo query strings que podem ter tokens, e-mails, IDs. Imagine https://seusite.com/reset?token=abc123 ser enviado pro Google Analytics, pro Facebook, pra qualquer link clicado na página.

strict-origin-when-cross-origin é o melhor default: envia origem completa pra requests dentro do site, só a origem (sem path) pra requests cross-origin, e nada pra HTTP saindo de HTTPS.

Como verificar agora

Você consegue checar manualmente abrindo o DevTools do navegador → Network → clica no documento → aba Headers. Mas é tedioso pra fazer pra cada página.

Ferramentas que automatizam:

• securityheaders.com — checagem pública, dá nota A-F
• Sentinela — probe de Headers verifica os 5 acima + qualidade da CSP (unsafe-inline, wildcards, Trusted Types), HSTS preload, COOP/COEP, e marca disclosure (Server, X-Powered-By)

A linha de base mínima

Se você só vai adicionar uma coisa hoje, adicione:

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin

Esses três não quebram nada e fecham as portas mais óbvias. HSTS e CSP merecem mais cuidado mas o ROI é altíssimo — especialmente CSP pra apps que processam dados sensíveis.

Headers HTTP são literalmente a defesa mais barata da web. Você muda a configuração do servidor, dá deploy, e tá feito. Não tem desculpa pra não ter.