Porquê analisar os seus headers HTTP de segurança?
Os headers HTTP de segurança formam a primeira linha de defesa do seu site na camada do navegador. Sem CSP, sem HSTS, sem X-Frame-Options, deixa aos atacantes ângulos de ataque que os padrões modernos sabem fechar. Um teste de segurança de site regular permite detetar esses esquecimentos antes que se transformem em incidente.
O nosso analisador recupera os headers HTTP devolvidos pelo seu servidor, confronta-os com as recomendações da OWASP e da Mozilla e, em seguida, calcula uma pontuação ponderada acompanhada de uma nota de A a F. Em 30 segundos, obtém uma visão clara das lacunas a corrigir.
Três casos de uso principais:
- Auditoria de entrada em produção: validar a configuração dos security headers antes da abertura pública
- Acompanhamento de conformidade: preparar uma auditoria PCI DSS, ISO 27001 ou SOC 2 que exige esses controlos
- Resposta a incidente: verificar que nenhum header HTTP crítico foi removido após uma atualização do servidor
Como usar o analisador em 3 etapas
Etapa 1: inserir a URL a testar
Indique a URL completa a analisar, por exemplo https://captaindns.com. A ferramenta aceita URL públicas acessíveis tanto em HTTPS como em HTTP e segue a cadeia de redirecionamentos (até 5 saltos).
Etapa 2: iniciar a análise dos headers
Clique em Inspecionar cabeçalhos. O servidor realiza um pedido GET à URL, captura todos os headers HTTP devolvidos e, em seguida, aplica as regras de scoring aos 10 security headers monitorizados.
Etapa 3: ler a nota e as recomendações
Vai obter:
- A nota de A a F e a pontuação sobre 100
- O detalhe header por header com o estado presente/ausente
- Os valores recomendados para cada header ausente
- Os tooltips pedagógicos que explicam o papel de cada header
O que são os headers HTTP de segurança?
Um header HTTP é uma linha de metadados enviada pelo servidor além do conteúdo da página. Os security headers são uma família específica de headers que controlam o comportamento do navegador para bloquear ou limitar os ataques do lado do cliente.
Quando o seu navegador carrega https://captaindns.com, o servidor devolve primeiro os seus headers HTTP antes do HTML. Esses headers indicam, por exemplo: «Forçar HTTPS durante um ano» (HSTS), «Executar apenas os scripts do mesmo domínio» (CSP), ou «Recusar ser apresentado num iframe» (X-Frame-Options).
Exemplo de headers HTTP devolvidos por um site seguro:
HTTP/2 200
strict-transport-security: max-age=31536000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self'
x-content-type-options: nosniff
x-frame-options: DENY
referrer-policy: strict-origin-when-cross-origin
permissions-policy: geolocation=(), microphone=()
Sem esses security headers, o navegador aplica comportamentos padrão muito mais permissivos, herdados dos primórdios da web.
Os 10 headers analisados e o seu papel
A ferramenta avalia 10 headers HTTP, cada um com um peso que reflete o seu impacto na postura de segurança.
| Header HTTP | Peso | Papel | Valor de exemplo |
|---|---|---|---|
| Strict-Transport-Security | 3.0 | Força HTTPS e impede o sslstrip | max-age=31536000; includeSubDomains; preload |
| Content-Security-Policy | 3.0 | Bloqueia XSS e injeção de scripts | default-src 'self'; script-src 'self' |
| Content-Security-Policy-Report-Only | 0.5 | CSP em modo observação, sem bloqueio | default-src 'self'; report-uri /csp-report |
| X-Frame-Options | 1.0 | Impede o clickjacking via iframe | DENY ou SAMEORIGIN |
| X-Content-Type-Options | 1.0 | Bloqueia o MIME sniffing | nosniff |
| Referrer-Policy | 1.0 | Limita a fuga de URL via Referer | strict-origin-when-cross-origin |
| Permissions-Policy | 1.0 | Restringe as APIs do navegador (câmara, microfone, geolocalização) | geolocation=(), microphone=() |
| Cross-Origin-Opener-Policy | 0.5 | Isola o contexto de navegação | same-origin |
| Cross-Origin-Embedder-Policy | 0.5 | Controla os recursos cross-origin carregados | require-corp |
| Cross-Origin-Resource-Policy | 0.5 | Define quem pode carregar os seus recursos | same-origin ou same-site |
Os seis headers críticos e standard formam a base da pontuação, sobre 10 pontos (HSTS e CSP contam 3 cada). Os quatro headers avançados (Cross-Origin-* e CSP-Report-Only) rendem um bónus que pode compensar uma configuração parcial, sem nunca ultrapassar esse limite de 10. Dois headers herdados, hoje obsoletos, retiram pontos se estiverem presentes: X-XSS-Protection (-0,5 assim que está presente) e X-Permitted-Cross-Domain-Policies (-0,2 se o valor não for none). A pontuação é depois convertida para 100 para produzir a nota final.
Como é calculada a sua nota de A a F?
O cálculo aplica uma lógica simples e reproduzível.
Etapa 1: pontuação bruta
Cada header crítico ou standard presente e corretamente configurado rende o seu peso completo. Um header presente mas mal configurado (ex. HSTS com max-age demasiado curto) rende um peso reduzido. O total bruto máximo é de 10 pontos.
Etapa 2: conversão sobre 100
A pontuação bruta é convertida para 100 por regra de três: score = (bruto / 10) × 100.
Etapa 3: atribuição da nota
| Nota | Pontuação sobre 100 | Interpretação |
|---|---|---|
| A+ | >= 95 | Segurança exemplar, com HSTS e CSP no nível máximo |
| A | >= 70 | Postura sólida, conforme as melhores práticas 2026 |
| B | >= 55 | Configuração correta, alguns headers a completar |
| C | >= 40 | Configuração parcial, headers críticos a reforçar |
| D | >= 20 | Postura fraca, vários security headers ausentes |
| F | < 20 | Proteção insuficiente, ação urgente recomendada |
A reter: o HSTS e o CSP pesam juntos 6 pontos em 10, ou seja, mais de metade da pontuação. A sua ausência faz descer mecanicamente a nota em pelo menos dois níveis.
Casos de uso concretos
Incidente 1: site com nota F após remodelação
Sintoma: após a migração para uma nova framework, o site obtém F, quando tinha B antes da remodelação.
Diagnóstico: o analisador revela a ausência de CSP, HSTS e X-Frame-Options. Os headers eram adicionados pelo antigo servidor Nginx e removidos durante a passagem para um alojamento gerido que não os inclui por predefinição.
Ação: adicionar os security headers na configuração da nova framework (next.config.js, middleware Express, etc.) e, em seguida, reiniciar a análise para confirmar o regresso à nota B ou A.
Incidente 2: auditoria de conformidade bloqueada
Sintoma: o auditor reporta a ausência de security headers como um finding importante, bloqueando a certificação PCI DSS.
Diagnóstico: o teste de segurança de site confirma HSTS ausente, CSP ausente, Referrer-Policy não definido. O servidor Apache serve a configuração predefinida sem adições.
Ação: configurar as diretivas Header set no vhost Apache, fazer o deploy em staging, iniciar o analisador para verificar a nota e depois enviar para produção. Repetir o teste para fornecer ao auditor o relatório conforme.
Incidente 3: clickjacking detetado em bug bounty
Sintoma: um investigador de segurança reporta, através de um bug bounty, que consegue incorporar o painel do cliente num iframe malicioso.
Diagnóstico: o analisador mostra X-Frame-Options ausente e CSP sem diretiva frame-ancestors. O navegador autoriza, portanto, a incorporação por predefinição.
Ação: adicionar X-Frame-Options: DENY e frame-ancestors 'none' no CSP. Reiniciar a análise para confirmar o encerramento da falha e fechar o ticket de bug bounty.
FAQ - Perguntas frequentes
P: O que é um analisador de headers HTTP?
R: Um analisador de headers HTTP é uma ferramenta que inspeciona os headers devolvidos por um servidor web durante um pedido. Verifica a presença e a configuração dos security headers como CSP, HSTS ou X-Frame-Options. O nosso analisador recupera esses headers HTTP, avalia a sua conformidade com as boas práticas OWASP e atribui uma nota de A a F. É a base de um teste de segurança de site completo e rápido.
P: Quais security headers são indispensáveis em 2026?
R: Os headers críticos em 2026 são Content-Security-Policy (CSP) para bloquear scripts não autorizados, Strict-Transport-Security (HSTS) para forçar HTTPS, X-Content-Type-Options para impedir o MIME sniffing, X-Frame-Options ou frame-ancestors CSP contra o clickjacking, e Referrer-Policy para limitar a fuga de URL. Permissions-Policy e Cross-Origin-Opener-Policy completam uma postura moderna. Sem esses headers HTTP, o seu site continua exposto a ataques conhecidos.
P: Qual é a diferença entre CSP e HSTS?
R: O CSP (Content-Security-Policy) controla as fontes autorizadas para carregar scripts, estilos, imagens ou iframes. Protege contra o XSS e a injeção de conteúdo. O HSTS (Strict-Transport-Security) força o navegador a aceder ao site apenas por HTTPS, impedindo os ataques de downgrade. O CSP atua ao nível do conteúdo da página, o HSTS ao nível do transporte. Ambos os headers HTTP são complementares e indispensáveis para uma nota de segurança elevada.
P: Como adicionar security headers ao meu site?
R: Depende do seu stack:
- Nginx: diretivas
add_headerno bloco server - Apache:
Header setno .htaccess ou na conf vhost - Cloudflare: Transform Rules ou Workers
- Next.js:
headers()no next.config.js - Express: middleware
helmet - Laravel: middleware dedicado
Após o deploy, reinicie a análise para confirmar que os headers HTTP são devolvidos corretamente.
P: Security headers ausentes são uma vulnerabilidade?
R: Headers ausentes não são uma vulnerabilidade direta, mas removem camadas de defesa. Sem CSP, uma falha XSS torna-se totalmente explorável. Sem HSTS, o utilizador continua vulnerável ao sslstrip numa rede hostil. Sem X-Frame-Options, o seu site pode ser incorporado num iframe para clickjacking. Os auditores PCI DSS, ISO 27001 e SOC 2 consideram esses headers HTTP como controlos de segurança esperados.
P: Esta ferramenta de teste de segurança de site é gratuita?
R: Sim, o nosso analisador de headers HTTP é totalmente gratuito, sem registo nem limite de utilização. Inicie os testes de segurança de site que precisar, em qualquer URL pública. Os resultados incluem a nota de A a F, o detalhe de cada header analisado e as recomendações de configuração. Nenhum dado é conservado além do tempo necessário ao cálculo da pontuação.
Ferramentas complementares
| Ferramenta | Utilidade |
|---|---|
| Auditoria on-page completa | Analisar o HTML, as tags SEO e os recursos de uma página |
| Teste HSTS | Verificar o cabeçalho Strict-Transport-Security e a elegibilidade para a preload list |
| Análise de redirecionamentos | Seguir a cadeia de redirecionamentos HTTP e detetar loops |
| Deteção de phishing | Verificar se uma URL está sinalizada como phishing |
| Validação DNSSEC | Confirmar a assinatura criptográfica da sua zona DNS |
| Conformidade MTA-STS | Verificar a política MTA-STS publicada para o seu domínio |
| Monitorização uptime | Vigiar a disponibilidade dos seus endpoints HTTP em multi-região |
Recursos úteis
- MDN - HTTP security headers (referência completa Mozilla)
- OWASP Secure Headers Project (recomendações OWASP)
- RFC 6797 - HTTP Strict Transport Security (especificação HSTS)
- MDN - X-Frame-Options (documentação X-Frame-Options)
- Content-Security-Policy Reference (referência CSP com exemplos)