Cabeçalhos de Segurança Que Todo Site Deve Enviar

Você protegeu seu servidor, atualizou seu framework e treinou sua equipe em codificação segura. No entanto, seu site continua vulnerável se não enviar os cabeçalhos HTTP de segurança corretos. Esses cabeçalhos de resposta informam aos navegadores como se comportar ao lidar com seu conteúdo, e cabeçalhos ausentes ou mal configurados deixam a porta aberta para cross-site scripting (XSS), clickjacking, ataques de downgrade de protocolo e vazamento de dados.

Neste guia, abordaremos os cabeçalhos de segurança essenciais que todo site deve enviar, explicaremos o que cada um faz e mostraremos como configurá-los corretamente.

Por que os Cabeçalhos de Segurança Importam

Os cabeçalhos de segurança são a primeira linha de defesa porque impõem políticas em nível de navegador que você controla. Eles não substituem a validação de entrada ou autenticação segura, mas reduzem significativamente a superfície de ataque. Por exemplo, uma Content-Security-Policy estrita pode impedir a execução de um script injetado, mesmo que um atacante encontre uma falha de XSS.

Os principais navegadores suportam esses cabeçalhos de forma consistente, e adicioná-los geralmente envolve algumas linhas de configuração. Há pouca razão para não usá-los.

Os Cabeçalhos de Segurança Essenciais

Abaixo estão os cabeçalhos que todo site em produção deve enviar. Abordaremos o que eles fazem, valores recomendados e armadilhas comuns.

1. Content-Security-Policy (CSP)

CSP é o cabeçalho mais poderoso para mitigar XSS e injeção de dados. Ele restringe de quais fontes o navegador pode carregar scripts, estilos, imagens e outros recursos. Uma boa política inicial pode ser assim:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';

Comece com default-src 'self' e adicione exceções gradualmente conforme necessário. Evite 'unsafe-inline' para scripts, se possível; use nonces ou hashes em vez disso. Teste minuciosamente, pois uma CSP mal configurada pode quebrar seu site.

2. HTTP Strict Transport Security (HSTS)

HSTS força os navegadores a usar HTTPS para todas as solicitações futuras ao seu domínio. Ele previne ataques de downgrade de protocolo e sequestro de cookies. Um cabeçalho típico:

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

O max-age está em segundos (um ano). includeSubDomains aplica a política a todos os subdomínios. preload permite que seu domínio seja adicionado às listas de pré-carregamento dos navegadores, mas só use se tiver certeza absoluta de que todos os subdomínios suportam HTTPS.

3. X-Frame-Options

Este cabeçalho impede que seu site seja incorporado em um iframe, o que bloqueia ataques de clickjacking. Use:

X-Frame-Options: DENY

Ou SAMEORIGIN se precisar enquadrar seu próprio conteúdo. Navegadores modernos também suportam a diretiva frame-ancestors na CSP, que é mais flexível. Se você usa CSP, pode omitir X-Frame-Options, mas incluir ambos proporciona melhor compatibilidade.

4. X-Content-Type-Options

Este cabeçalho impede que os navegadores façam MIME-sniffing de uma resposta divergindo do Content-Type declarado. É simples e eficaz:

X-Content-Type-Options: nosniff

Sem ele, um arquivo malicioso pode ser interpretado como script executável. Sempre defina-o.

5. Referrer-Policy

Referrer-Policy controla quanta informação de referrer é enviada com as solicitações. Um padrão equilibrado:

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

Isso envia a URL completa para solicitações de mesma origem e apenas a origem para solicitações de origem cruzada. Reduz o vazamento de informações de caminho sensíveis enquanto preserva a análise.

6. Permissions-Policy

Anteriormente Feature-Policy, este cabeçalho permite habilitar ou desabilitar recursos do navegador como geolocalização, câmera e microfone. Exemplo:

Permissions-Policy: geolocation=(), camera=(), microphone=()

Desabilitar recursos não utilizados reduz o impacto de scripts de terceiros comprometidos.

Comparação dos Cabeçalhos de Segurança

Como Adicionar Cabeçalhos de Segurança

O método depende do seu servidor web ou framework. Aqui estão abordagens comuns.

Nginx

Adicione cabeçalhos no seu bloco de servidor:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;

O parâmetro always garante que os cabeçalhos sejam enviados mesmo em respostas de erro.

Apache

Habilite mod_headers e adicione:

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; object-src 'none'; base-uri 'self'; form-action 'self';"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "DENY"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"

Node.js (Express)

Use o middleware helmet, que define muitos cabeçalhos por padrão:

const helmet = require('helmet');
app.use(helmet());
// Personalize a CSP se necessário
app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'", "https://trusted.cdn.com"],
    styleSrc: ["'self'", "'unsafe-inline'"],
    imgSrc: ["'self'", "data:", "https://images.example.com"],
    objectSrc: ["'none'"],
    baseUri: ["'self'"],
    formAction: ["'self'"],
  }
}));

O Helmet também define outros cabeçalhos como X-Content-Type-Options e Referrer-Policy por padrão.

Testando Seus Cabeçalhos

Após a implantação, verifique seus cabeçalhos usando as ferramentas de desenvolvedor do navegador (aba Network) ou scanners online como SecurityHeaders.com. Verifique se:

• Todos os cabeçalhos recomendados estão presentes.
• A CSP não bloqueia recursos legítimos (verifique o console para violações).
• O HSTS só está habilitado se o HTTPS estiver funcionando plenamente.
• Os cabeçalhos são enviados também em páginas de erro.

Revise e atualize regularmente suas políticas conforme seu site evolui.

FAQ

Qual é o cabeçalho de segurança mais importante?

Content-Security-Policy é frequentemente considerado o mais importante porque mitiga diretamente ataques de XSS e injeção de dados, que estão entre as vulnerabilidades web mais comuns.

Os cabeçalhos de segurança podem substituir outras medidas de segurança?

Não. Os cabeçalhos de segurança são uma camada de defesa em profundidade. Você ainda precisa de codificação segura, validação de entrada, autenticação e outras boas práticas.

Adicionar cabeçalhos de segurança pode quebrar meu site?

Se mal configurados, especialmente a CSP, eles podem bloquear recursos legítimos. Sempre teste em um ambiente de staging e monitore o console do navegador para violações antes de implantar em produção.

Pronto para proteger seu site? Comece adicionando os cabeçalhos acima e depois teste com as ferramentas de desenvolvedor do seu navegador. Para uma maneira rápida de inspecionar e formatar respostas JSON do seu scanner de segurança, experimente nosso JSON Formatter.