Headers de Segurança HTTP: Seu Site Tem Nota F Sem Você Saber

Existe um teste de segurança que qualquer pessoa pode rodar agora mesmo no seu site. O resultado aparece em segundos: uma nota de A+ até F. E a maioria esmagadora dos sites na internet — incluindo de grandes empresas — tira F ou D.

Não porque foram hackeados. Não porque têm vulnerabilidades no código. Mas porque nunca configuraram proteções básicas que existem há anos, são gratuitas, e levam menos de 5 minutos para ativar.

São os headers de segurança HTTP. E o seu site provavelmente está sem eles agora.

O que São Headers de Segurança HTTP

Toda vez que um navegador acessa uma página, o servidor responde com dois componentes: o conteúdo da página (HTML, CSS, JS) e um conjunto de headers HTTP — metadados invisíveis que instruem o navegador sobre como se comportar.

A maioria dos desenvolvedores conhece headers como Content-Type ou Cache-Control. Mas existe uma categoria inteira de headers voltada exclusivamente para segurança, que diz ao navegador coisas como:

• "Nunca carregue este site via HTTP, apenas HTTPS"
• "Não permita que esta página seja exibida dentro de um iframe"
• "Bloqueie qualquer script que não venha dos meus próprios servidores"

Quando esses headers estão ausentes, o navegador usa comportamentos padrão permissivos — que abrem brechas para clickjacking, injeção de scripts, roubo de dados e uma série de ataques que já têm décadas de histórico documentado.

A boa notícia: configurar esses headers não exige reescrever código. É uma linha de configuração no seu servidor web ou CDN.

Os 6 Headers Essenciais (e Como Configurar Cada Um)

1. HSTS — HTTP Strict Transport Security

O que protege: Força o navegador a usar sempre HTTPS, eliminando ataques de downgrade onde um atacante intercepta a conexão e a degrada para HTTP não criptografado.

O problema sem ele: Mesmo que seu site use HTTPS, um usuário que digita meusite.com faz a primeira requisição via HTTP antes de ser redirecionado. Esse milissegundo é suficiente para um ataque man-in-the-middle.

Como configurar:

Nginx:

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

Apache:

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

Cloudflare: Ative em SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS).

O max-age=31536000 define 1 ano de validade. O preload permite que seu domínio entre na lista de pré-carregamento dos navegadores — após isso, nem a primeira requisição HTTP é feita.

2. Content-Security-Policy (CSP)

O que protege: Define exatamente quais fontes de conteúdo são permitidas — scripts, estilos, imagens, fontes, iframes. É a principal defesa contra ataques XSS (Cross-Site Scripting).

O problema sem ele: Se um atacante conseguir injetar um <script> malicioso na sua página (via comentário, campo de formulário, dependência comprometida), o navegador executa sem questionar.

Como configurar:

Nginx:

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:; font-src 'self'; frame-ancestors 'none';" always;

Apache:

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:; font-src 'self'; frame-ancestors 'none';"

Cloudflare: Adicione via Rules → Transform Rules → Response Header Modification.

CSP é o header mais complexo de configurar corretamente, pois varia conforme o que seu site carrega. Use o modo Content-Security-Policy-Report-Only primeiro para identificar bloqueios sem quebrar o site.

3. X-Frame-Options

O que protege: Impede que sua página seja carregada dentro de um <iframe> em outro domínio, bloqueando ataques de clickjacking — onde o atacante sobrepõe sua página invisível sobre outra para capturar cliques.

O problema sem ele: Um site malicioso pode criar um iframe transparente com a sua página de login sobreposta sobre um botão "Ganhe um prêmio". O usuário digita as credenciais sem saber.

Como configurar:

Nginx:

add_header X-Frame-Options "DENY" always;

Apache:

Header always set X-Frame-Options "DENY"

Cloudflare: Ative em SSL/TLS → Edge Certificates ou via Transform Rules.

Use DENY para bloquear completamente, ou SAMEORIGIN se você precisar carregar a própria página em iframes internos. Nota: se você já usa CSP com frame-ancestors, ele tem precedência em navegadores modernos — mas mantenha X-Frame-Options para suporte a navegadores antigos.

4. X-Content-Type-Options

O que protege: Impede que o navegador "adivinhe" o tipo de conteúdo de um arquivo quando o servidor não especifica claramente. Sem esse header, um arquivo .txt com código JavaScript pode ser executado como script.

O problema sem ele: Um atacante que consiga fazer upload de um arquivo no seu servidor (uma imagem, por exemplo) pode construir o conteúdo de forma que o navegador o interprete como JavaScript executável.

Como configurar:

Nginx:

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

Apache:

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

Cloudflare: Disponível em Managed Headers ou via Transform Rules.

Este é o header mais simples da lista. Uma palavra, zero risco de quebrar funcionalidades, proteção imediata.

5. Referrer-Policy

O que protege: Controla quanta informação da URL de origem é enviada quando um usuário clica em um link para outro site. Sem controle, a URL completa — incluindo parâmetros de sessão, tokens e dados sensíveis — pode vazar para terceiros.

O problema sem ele: Se sua URL de painel é app.meusite.com/dashboard?token=abc123 e você tem um link para um blog externo, esse token pode aparecer no log de acesso do site externo.

Como configurar:

Nginx:

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

Apache:

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

strict-origin-when-cross-origin é o equilíbrio ideal: envia a URL completa em requisições do mesmo domínio, mas apenas o domínio de origem (sem path ou parâmetros) em requisições cross-origin.

6. Permissions-Policy

O que protege: Define quais APIs do navegador seu site pode usar — câmera, microfone, geolocalização, notificações, acelerómetro. Limita o acesso mesmo que um script malicioso seja injetado.

O problema sem ele: Um script de terceiro (widget, analytics, publicidade) pode solicitar acesso à câmera ou geolocalização do usuário em nome do seu domínio.

Como configurar:

Nginx:

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

Apache:

Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()"

A sintaxe () significa "ninguém tem acesso". Se seu site usa geolocalização, substitua por geolocation=(self).

Como Verificar a Nota do Seu Site Agora

Configurar os headers é metade do trabalho. A outra metade é verificar se estão sendo enviados corretamente — em todas as páginas, incluindo subdomínios.

O Security Headers Checker do FlashMon analisa qualquer URL e retorna:

• Nota de A+ até F baseada nos headers presentes e ausentes
• Quais headers estão configurados corretamente
• Quais estão faltando e qual o risco de cada ausência
• Análise de CSP, HSTS, X-Frame-Options e todos os outros

A análise é gratuita e instantânea. Você também pode combinar com o SSL Checker para garantir que o certificado TLS está válido, e o HTTP Status Checker para confirmar que os redirecionamentos HTTP→HTTPS estão funcionando antes do HSTS entrar em ação.

Checklist Rápido de Implementação

Use esta lista antes de publicar qualquer site em produção:

Headers obrigatórios (nota mínima B sem eles):

• Strict-Transport-Security com max-age de pelo menos 6 meses
• X-Frame-Options: DENY ou SAMEORIGIN
• X-Content-Type-Options: nosniff

Headers recomendados (diferença entre B e A+):

• Content-Security-Policy com default-src 'self' como base
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy restringindo câmera, microfone e geolocalização

Verificações pós-configuração:

• Rodar o Security Headers Checker do FlashMon na homepage
• Testar também em páginas internas (blog, painel, login)
• Verificar subdomínios separadamente — www e api têm headers independentes
• Confirmar que o HTTPS está funcionando antes de ativar HSTS com preload
• Monitorar erros de CSP no console do navegador após deploy

Armadilhas comuns:

• Headers configurados no servidor mas sobrescritos pelo CDN (ou vice-versa)
• CSP bloqueando scripts legítimos de analytics ou chat — teste em staging primeiro
• HSTS ativado antes de garantir que HTTPS funciona — pode tornar o site inacessível

---

Segurança não é binária. Não existe site "100% seguro", mas existe site que dificulta o trabalho do atacante versus site que facilita. Configurar headers de segurança é uma das poucas medidas onde o esforço é mínimo e o impacto é imediato.

Cinco minutos de configuração. Uma nota A+ na auditoria. E a tranquilidade de saber que as proteções básicas estão no lugar.

Verifique agora a nota de segurança do seu site →

---

Continue lendo

• Cada porta aberta é mais superfície de ataque — veja o guia para fechar portas desnecessárias e rode o Port Scanner.
• Valide o certificado que o HSTS coloca em jogo com o verificador SSL.