Headers HTTP de segurança: guia completo para 2026

O que são os headers HTTP de segurança

Headers HTTP de segurança são cabeçalhos de resposta que o servidor web envia junto com cada página HTML, instruindo o navegador sobre como se comportar em relação a scripts, frames, conexões e outros recursos. Eles são a segunda linha de defesa mais importante depois do código da aplicação: quando uma vulnerabilidade passa despercebida, esses cabeçalhos podem limitar drasticamente o impacto de uma exploração bem sucedida.

A boa noticia e que configurar headers de segurança e simples, rapido e não requer mudancas no código da aplicação - apenas ajustes no servidor web (Nginx, Apache, Caddy) ou no middleware da aplicação. A ma noticia e que a maioria dos sites ainda não tem esses cabeçalhos configurados. O site securityheaders.com, que analisa headers publicamente, atribui nota F (reprovado) para mais de 60% dos sites populares que analisa.

Como funcionam os principais headers

Cada header de segurança instrui o navegador sobre uma categoria específica de comportamento. Vejamos os mais importantes:

Content-Security-Policy (CSP) e o mais poderoso e complexo. Ele define exatamente de onde scripts, estilos, fontes, imagens e outros recursos podem ser carregados. Um CSP bem configurado bloqueia a execução de scripts inline injetados por XSS, mesmo que a vulnerabilidade exista na aplicação. Exemplo mínimo: Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.trusted.com; object-src 'none';

HTTP Strict-Transport-Security (HSTS) instrui o navegador a sempre usar HTTPS para o domínio, mesmo que o usuário tente acessar via HTTP. Previne ataques de downgrade SSL e interceptação de conexão em redes públicas. Exemplo: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. A diretiva preload permite adicionar o domínio a lista global de HSTS preload mantida pelo Google.

X-Frame-Options (em processo de substituição por CSP frame-ancestors) impede que a página seja carregada dentro de um iframe em outros domínios. Protege contra ataques de clickjacking, onde o atacante sobrepos a página legítima com um iframe invisível para induzir cliques. Valor recomendado: X-Frame-Options: SAMEORIGIN

X-Content-Type-Options impede que o navegador infira o tipo de conteúdo de um arquivo quando o Content-Type declarado e diferente do conteúdo real. Previne um vetor de ataque onde um arquivo de imagem e interpretado como JavaScript. Valor único: X-Content-Type-Options: nosniff

Permissions-Policy (antigamente Feature-Policy) controla quais APIs do navegador a página pode usar e em quais contextos: camera, microfone, geolocalização, acelerometro, etc. Exemplo restritivo: Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(self)

Referrer-Policy controla quanta informação sobre a URL atual e enviada no header Referer quando o usuário navega para outro site. Valor recomendado para privacidade: Referrer-Policy: strict-origin-when-cross-origin

Cross-Origin-Opener-Policy (COOP) e Cross-Origin-Embedder-Policy (COEP) controlam o isolamento de contexto entre origens. Necessarios para habilitar SharedArrayBuffer e medir tempo de alta resolução. Recomendado: Cross-Origin-Opener-Policy: same-origin e Cross-Origin-Embedder-Policy: require-corp

Quem e afetado pela ausencia desses headers

Qualquer site que serve HTML sem os headers de segurança está sujeito a:

- Clickjacking: ataques de UI redressing onde um iframe invisível sobrepos botoes do site real para capturar cliques (sem X-Frame-Options ou CSP frame-ancestors)

- Amplificação de XSS: um XSS que sem CSP pode executar qualquer script, fazer requisições a qualquer domínio e roubar dados sem restrição

- Downgrade de SSL: usuários em redes públicas sendo redirecionados de HTTPS para HTTP por atacantes MitM (sem HSTS)

- MIME sniffing: arquivos enviados por usuários sendo executados como scripts no navegador (sem nosniff)

- Vazamento de informação via Referer: tokens de autenticação na URL sendo enviados para sites terceiros via header Referer

Como identificar headers ausentes

Para uma análise completa e com nota automatizada, use securityheaders.com ou o TrustSiteMonitor, que verifica a presença e qualidade de todos os headers de segurança como uma das 26 fases de análise automatizada, com recomendações específicas para cada header ausente ou mal configurado.

Como configurar no Nginx

Adicione os headers no bloco server do arquivo de configuração Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

add_header X-Content-Type-Options "nosniff" always;

add_header X-Frame-Options "SAMEORIGIN" always;

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://cdn.seudominio.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self'; frame-src 'none'; object-src 'none';" always;

Importante: a diretiva always garante que o header e enviado mesmo em respostas de erro (4xx, 5xx). Sem ela, erros não tem os headers aplicados.

Como configurar no Apache

No arquivo .htaccess ou na configuração do VirtualHost:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Header always set X-Content-Type-Options "nosniff"

Header always set X-Frame-Options "SAMEORIGIN"

Header always set Referrer-Policy "strict-origin-when-cross-origin"

Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';"

Certifique-se que o módulo mod_headers está habilitado: a2enmod headers && systemctl reload apache2

Análise técnica do CSP

O Content Security Policy merece atenção especial por ser o mais complexo e o mais poderoso. Uma política CSP e composta de diretivas, cada uma controlando uma categoria de recurso:

default-src: fallback para todas as diretivas não especificadas. Use 'self' como baseline restritiva.

script-src: controla scripts. 'unsafe-inline' e 'unsafe-eval' devem ser evitados pois anulam a proteção XSS. Prefira nonces: script-src 'nonce-VALOR_ALEATORIO_POR_REQUEST'

object-src 'none': bloqueia Flash e plugins legados. Sempre configure isso.

base-uri 'self': previne ataques via injeção de tag base que redireciona todas as URLs relativas.

form-action 'self': impede que formularios enviem dados para domínios externos.

Para sites com CDNs, analitica e fontes externas, o CSP precisa listar cada domínio externo explicitamente. Ferramentas como o Report-URI.com ajudam a coletar violações em modo Content-Security-Policy-Report-Only antes de ativar o CSP em modo de bloqueio.

Impacto e consequencias da ausencia

Sites sem headers de segurança são mais fáceis de explorar após uma vulnerabilidade primaria ser encontrada. Segundo o relatorio da HackerOne de 2024, 35% dos reports de bug bounty de alta severidade mencionam a ausencia de headers como fator agravante que permitiu maior impacto após a exploração inicial. Do ponto de vista regulatório, OWASP considera headers de segurança como controles básicos. Auditorias de conformidade PCI-DSS e SOC 2 verificam a presença de HSTS e X-Content-Type-Options como itens obrigatórios.

Dicas práticas e boas práticas

1. Comece com os headers não disruptivos que não quebram nada: X-Content-Type-Options, X-Frame-Options, Referrer-Policy e Permissions-Policy podem ser ativados imediatamente.

2. Active o HSTS em modo test primeiro: use max-age=300 (5 minutos) e confirme que tudo funciona em HTTPS antes de aumentar para 31536000 (1 ano).

3. Para CSP, comece em modo Report-Only: Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violations. Colete violações por uma semana, identifique fontes legítimas, e então mude para modo de bloqueio.

4. Não coloque 'unsafe-inline' em script-src se puder evitar. Se precisar, use nonces gerados por request em vez de permissão global.

5. Verifique após configurar com o securityheaders.com e com o TrustSiteMonitor para confirmar que todos os headers estão sendo enviados corretamente, incluindo em páginas de erro.

6. Revise periodicamente: novos headers como Cross-Origin-Opener-Policy foram adicionados nos últimos anos. O que era completo em 2020 pode estar desatualizado em 2026.

Conclusao: o que fazer agora

Acesse agora o securityheaders.com, insira a URL do seu site e veja a nota. Se for abaixo de B, você tem trabalho a fazer. A configuração dos headers essenciais leva menos de 30 minutos em qualquer servidor web e melhora significativamente a postura de segurança do site sem requerer nenhuma mudanca no código da aplicação.

Use o TrustSiteMonitor para uma análise completa que verifica não apenas a presença dos headers mas também a qualidade da configuração: um CSP com 'unsafe-inline' e detectado como configuração fraca, por exemplo, mesmo que o header esteja presente.

Headers HTTP de segurança: o escudo invisível do seu site