Quais cabeçalhos de segurança o seu site envia

O que um cabeçalho de segurança faz

Toda resposta HTTP traz cabeçalhos: metadados que o navegador lê antes de renderizar qualquer coisa. Alguns deles são instruções de segurança — o servidor dizendo ao navegador o que não permitir naquela página.

O ponto que costuma escapar é que essas defesas só existem se o servidor pedir. O navegador não aplica nenhuma delas por padrão, porque quebraria a web antiga. Um site sem esses cabeçalhos não está com a proteção desligada por engano: ela nunca foi ligada.

São, quase sempre, uma linha de configuração cada. É o melhor retorno por esforço em segurança de aplicação — e é justamente por isso que aparecem em quase todo questionário de homologação de fornecedor e em formulário de seguro cyber.

HSTS: forçar HTTPS de verdade

Redirecionar HTTP para HTTPS não é suficiente. A primeira requisição ainda sai em texto claro, e quem estiver no caminho — um Wi-Fi hostil, um provedor comprometido — pode interceptar antes do redirecionamento acontecer.

Strict-Transport-Security fecha isso: depois da primeira visita bem-sucedida, o navegador guarda que este domínio só fala HTTPS e passa a recusar HTTP sozinho, sem nem tentar a conexão. O max-age define por quanto tempo ele lembra.

Duas decisões acompanham. includeSubDomains estende a regra a todos os subdomínios — e derruba qualquer um que ainda sirva só HTTP, então confira antes. E preload inscreve o domínio numa lista embutida nos navegadores, o que protege até a primeira visita; é um compromisso sério, porque sair da lista leva meses.

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

CSP: o mais poderoso e o mais chato

Content-Security-Policy declara de onde a página pode carregar cada tipo de recurso. É a defesa mais eficaz contra injeção de script: mesmo que um atacante consiga inserir código na página, o navegador se recusa a executá-lo se a origem não estiver autorizada.

Também é o cabeçalho que mais quebra site quando mal configurado, e por isso o mais adiado. A saída é publicar primeiro em Content-Security-Policy-Report-Only: o navegador não bloqueia nada, só reporta o que teria bloqueado. Rode assim por algumas semanas, ajuste, e só então troque o nome do cabeçalho.

Nem toda política vale o mesmo. Uma que inclui 'unsafe-inline' em script-src perde a maior parte da eficácia contra injeção, porque script inline é exatamente o vetor mais comum. Em página renderizada dinamicamente, a alternativa é nonce por requisição. Em página estática pré-renderizada isso não é possível, e a escolha honesta é assumir o 'unsafe-inline' e fechar todo o resto — não fingir que a política é estrita.

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

Os quatro cabeçalhos de uma linha

• X-Content-Type-Options: nosniff — impede o navegador de adivinhar o tipo de um arquivo. Sem ele, um upload de usuário servido como texto pode acabar executado como script.
• Referrer-Policy — controla quanto da URL atual vaza para sites de terceiros nos links de saída. Sem política, a URL inteira vai junto, com tudo que houver no caminho e na query string.
• frame-ancestors (no CSP) ou X-Frame-Options — impede que outro site embuta o seu num iframe invisível para capturar cliques. O CSP é a forma moderna; o X-Frame-Options continua útil para navegador antigo.
• Permissions-Policy — desliga recursos que a página não usa, como câmera, microfone e localização. Reduz o que um script de terceiro comprometido consegue pedir em seu nome.

Erros que aparecem com mais frequência

O primeiro é configurar no lugar errado. Quando há CDN, proxy reverso e aplicação na mesma pilha, cada camada pode adicionar, sobrescrever ou remover cabeçalho. O que vale é o que chega ao navegador — e a única forma de saber é medir a resposta final, não ler o arquivo de configuração.

O segundo é cobrir só a home. Cabeçalho costuma ser configurado por rota ou por regra de caminho, e é comum a página inicial estar impecável enquanto a área de login, servida por outro bloco, não recebe nada.

O terceiro é tratar cabeçalho como se fosse a segurança do site. Ele é uma camada, e das mais baratas. Não substitui atualizar dependência, validar entrada, nem cuidar de autenticação — e um scanner com nota máxima em cabeçalhos não diz nada sobre o resto.

Como validar que a correção pegou

Cabeçalho aplica na hora: não há TTL nem propagação. Depois do deploy, rode a verificação de novo e o resultado já reflete a mudança — se não refletir, quase sempre é cache do CDN, e vale forçar a invalidação.

Confira também uma rota interna, não só a raiz, e teste em HTTP para confirmar que o redirecionamento para HTTPS acontece antes de qualquer conteúdo ser servido. Depois disso, o único cuidado é reconferir quando trocar de CDN, de hospedagem ou de framework — é nessas trocas que a configuração se perde.