Os cabeçalhos de segurança HTTP explicados para humanos

Quando lanças uma app com o Cursor, o Lovable ou o v0, o servidor responde a cada pedido com uma série de headers HTTP: instruções invisíveis que o browser obedece antes de desenhar o que quer que seja. Um punhado deles decide boa parte da segurança do teu site, e quase nenhum template os traz ativados. Este guia explica o que faz cada um, que valor pôr, os erros que partem coisas e como os configurar na Vercel, no Next.js, no Nuxt, na Netlify, na Cloudflare ou no nginx.

O que é um header e como ver os teus

Um header é uma linha de texto que acompanha a resposta, do tipo Nome: valor. O browser lê-a e muda o comportamento: deixar ou não carregar um script, forçar HTTPS, permitir ou não que a tua página entre num iframe. Podes vê-los nas ferramentas de programador (F12, separador Network, clique no documento principal, secção Response Headers) ou a partir do terminal:

curl -I https://oteudominio.com

Se nessa lista não aparecerem os de baixo, não estão configurados. Não há valores por defeito que te salvem.

Os sete que importam

Content-Security-Policy (CSP)

É a rainha. Diz ao browser de que origens pode carregar scripts, estilos, imagens, fontes e ligações. Se um atacante conseguir injetar um <script> na tua página, uma CSP bem feita impede que corra. Um ponto de partida honesto para uma app moderna:

Content-Security-Policy: default-src 'self'; script-src 'self' https://js.stripe.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://*.supabase.co; frame-ancestors 'none'; base-uri 'self'; form-action 'self'

O erro típico é pôr 'unsafe-inline' em script-src porque "senão não funciona": isso deita abaixo a proteção principal. As frameworks modernas resolvem os scripts inline com um nonce (um valor aleatório por pedido) ou com hashes. E a forma segura de começar é em modo de relatório: o header Content-Security-Policy-Report-Only não bloqueia nada, só te conta o que bloquearia. Deixa-o assim uns dias, revê os relatórios e passa-o ao header real quando já não partir nada.

Strict-Transport-Security (HSTS)

Obriga o browser a usar HTTPS durante o tempo indicado, mesmo que o utilizador escreva http:// ou clique num link antigo. Evita que alguém na mesma rede degrade a ligação. O valor habitual:

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

Ativa-o só quando todo o teu domínio e os subdomínios forem por HTTPS: se o puseres com um subdomínio em HTTP, deixa-lo inacessível durante um ano nos browsers que o tenham visto. Começa com um max-age curto se tiveres dúvidas.

X-Frame-Options e frame-ancestors

Impedem que o teu site seja carregado dentro de um <iframe> de outra página. Sem isto, alguém pode embutir a tua app num site falso e enganar os utilizadores para clicarem onde não devem: é o clickjacking. X-Frame-Options: DENY ou SAMEORIGIN resolve-o em browsers antigos; a versão moderna é a diretiva frame-ancestors dentro da CSP. Põe as duas.

X-Content-Type-Options

Um único valor: nosniff. Impede que o browser adivinhe o tipo de um ficheiro e execute como script algo que serviste como texto ou imagem. É uma linha; não há desculpa para faltar.

Referrer-Policy

Controla quanta informação do URL de origem é enviada ao navegar para outro site ou carregar um recurso externo. Sem controlo, podes deixar fugir caminhos privados ou tokens que viajam no URL. strict-origin-when-cross-origin é o equilíbrio sensato: o teu domínio sim, o caminho completo não.

Permissions-Policy

Declara que capacidades do browser a tua página e os seus iframes podem usar: câmara, microfone, geolocalização, pagamentos. Se não as usas, desativa-as; assim um script injetado ou um iframe de terceiros também não pode. Por exemplo: camera=(), microphone=(), geolocation=().

Cross-Origin-Opener-Policy

Menos conhecido: isola a tua janela das que a abriram ou que abriste com window.open, o que corta uma família de ataques entre separadores. same-origin é o valor habitual, salvo se dependeres de janelas pop-up de terceiros (alguns logins com OAuth), onde convém same-origin-allow-popups.

Os que convém tirar

X-Powered-By e um header Server com versão anunciam a tua stack exata a quem procure falhas conhecidas. No Next.js tira-se com poweredByHeader: false; no Express, com app.disable('x-powered-by'). E X-XSS-Protection está obsoleto: os browsers modernos ignoram-no e nos antigos chegou a causar falhas. Não o ponhas, ou põe-no a 0.

Como os pôr consoante o alojamento

Vercel, para qualquer framework, em vercel.json:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=31536000; includeSubDomains" },
        { "key": "X-Frame-Options", "value": "SAMEORIGIN" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" }
      ]
    }
  ]
}

Next.js: a função headers() do next.config.js, com a mesma lista; a CSP com nonce gera-se no middleware. Nuxt: routeRules no nuxt.config.ts com um objeto headers, ou um plugin de servidor se precisares de nonce. Netlify: um ficheiro _headers na pasta publicada:

/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin

Cloudflare: regras de transformação de headers de resposta no painel, sem tocar em código. nginx num VPS:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
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;

Deixo a CSP fora destes blocos de propósito: é a única que depende de que scripts e serviços a tua app usa, e convém construí-la em modo de relatório antes de a fixar.

Erros que partem coisas

HSTS antes de ter tudo em HTTPS. Deixa de fora quem tenha um subdomínio em HTTP. Verifica primeiro, ativa depois.
CSP sem nonce no Next.js ou no Nuxt. Ambos injetam scripts inline para hidratar a página; sem nonce, a CSP rigorosa bloqueia-os e a app fica em branco. Usa o mecanismo de nonce da framework.
Headers só no HTML. As rotas de API e os ficheiros estáticos também precisam deles, sobretudo nosniff. Aplica a regra a /(.*).
Headers duplicados. Se o CDN e a app acrescentam o mesmo, o browser pode ficar com o mais restritivo ou ignorar ambos. Decide um sítio.
Esquecer os subdomínios (app., api., docs.): cada um responde com os seus próprios headers.

Verifica-os por fora

Estes headers são informação pública: qualquer pessoa os pode ler, incluindo tu. O verificador gratuito de headers lista-te os que faltam e os que estão mal em segundos. E o Scanaris faz a verificação completa só de leitura, com mais umas 45 coisas, e por cada header ausente dá-te um fix prompt pronto a colar na tua IA com a linha exata para o teu alojamento. Não explora nada nem toca no teu servidor: lê e diz-te o que ativar. Se quiseres o contexto completo, está no guia de segurança para apps criadas com IA e na checklist de lançamento.

Perguntas frequentes

Os headers tornam o site mais lento?

Não. São umas centenas de bytes por resposta e o browser processa-os em microssegundos. O HSTS até o acelera, porque evita o redirecionamento de HTTP para HTTPS nas visitas seguintes.

O que acontece se um header partir algo em produção?

Tira-o ou relaxa-o e volta a publicar: o efeito é imediato, salvo o HSTS, que os browsers recordam durante o max-age. Por isso a CSP se testa em modo de relatório e o HSTS se ativa no fim.

Preciso de CSP se a minha app é pequena?

Se a tua app tem um formulário ou mostra conteúdo de utilizadores, sim: é a defesa que transforma um XSS num incidente menor. Começa pelos restantes headers, que são triviais, e acrescenta a CSP em modo de relatório quando puderes dedicar-lhe uma tarde.