Verificador de Headers HTTP
Analise cabeçalhos de resposta HTTP para verificar segurança, cache e informações do servidor.
Headers de Segurança que Verificamos
- • Strict-Transport-Security: Força HTTPS
- • Content-Security-Policy: Previne ataques XSS
- • X-Frame-Options: Previne clickjacking
- • X-Content-Type-Options: Previne MIME sniffing
- • X-XSS-Protection: Filtro XSS
Por que verificar Headers?
- • Identificar vulnerabilidades de segurança
- • Verificar configuração do servidor
- • Verificar políticas de cache
- • Depurar respostas de API
- • Analisar configurações de desempenho
O header de segurança que seu servidor está ignorando — e o que isso significa na prática
Headers HTTP de segurança são diretivas enviadas pelo servidor que dizem ao navegador como se comportar. Headers ausentes como Content-Security-Policy, X-Frame-Options e Strict-Transport-Security deixam seu site vulnerável a XSS, clickjacking e ataques de downgrade de protocolo.
Você obteve 40% no score de segurança. Isso não significa que seu site foi invadido — significa que sua resposta HTTP não inclui headers que os navegadores modernos usam para aplicar políticas de segurança. CSP bloqueia execução de scripts não autorizados. HSTS força HTTPS em visitas futuras. X-Frame-Options impede que suas páginas sejam embutidas em iframes para clickjacking. Cada header que você adiciona fecha uma superfície de ataque específica.
Usando headers HTTP para depurar cache, CORS e problemas de API
Quando usuários veem conteúdo desatualizado após um deploy, ou um cliente de API rejeita uma requisição cross-origin, a causa quase sempre está nos headers HTTP. Cache-Control, Vary e Access-Control-Allow-Origin controlam exatamente esses comportamentos.
Um header Cache-Control: max-age=86400 significa que o navegador vai servir conteúdo do cache por 24 horas — mesmo após você ter feito um deploy com correções. Erros de CORS por falta do Access-Control-Allow-Origin parecem falhas de rede no cliente, mas são problemas de configuração do servidor. Verificar os headers diretamente revela o que o servidor está enviando de fato, não o que você acha que configurou.
O que um score de segurança HTTP baixo indica para você corrigir
O score de segurança HTTP é a porcentagem de headers críticos que estão presentes e configurados corretamente. Um score abaixo de 60% significa que múltiplos headers estão ausentes, deixando usuários expostos a XSS, clickjacking e ataques de downgrade.
Comece pelos headers de maior impacto: HSTS força HTTPS em visitas repetidas e previne ataques SSL-strip. Content-Security-Policy restringe quais scripts e recursos podem ser executados na página. X-Frame-Options ou a diretiva frame-ancestors do CSP impede que sua página de login seja embutida em um iframe malicioso. Adicione esses três e seu score sobe significativamente.
Verificando headers Set-Cookie para identificar sessões configuradas de forma insegura
Um header Set-Cookie sem as flags Secure e HttpOnly significa que tokens de sessão são acessíveis por JavaScript e transmitidos via HTTP — ambos são riscos de segurança em produção.
Se sua aplicação usa cookies para autenticação, os headers de resposta revelam exatamente como eles estão configurados. Flag Secure ausente significa que cookies são enviados por HTTP. Flag HttpOnly ausente significa que o JavaScript pode ler o cookie — tornando ataques XSS imediatamente perigosos. SameSite=Lax ou Strict previne cross-site request forgery. Não são configurações abstratas — são valores que o servidor define por resposta.