Inspecionar Cabeçalhos HTTP
Inspecione os cabeçalhos HTTP de qualquer URL.
Porque analisar headers HTTP
Os headers HTTP transportam metadados críticos entre cliente e servidor: cache, segurança, conteúdo, compressão e políticas de execução. Uma configuração correta melhora performance, reduz risco de ataque e evita erros de indexação.
Em auditorias técnicas, os headers são uma das primeiras camadas a validar porque revelam rapidamente se o servidor está alinhado com boas práticas de web performance e hardening.
Headers de segurança que deve monitorizar
Strict-Transport-Security
Força HTTPS e reduz risco de downgrade para HTTP.
Content-Security-Policy
Controla origens permitidas de scripts e recursos.
X-Frame-Options
Mitiga clickjacking ao impedir iframes não autorizados.
X-Content-Type-Options
Evita MIME sniffing com valor nosniff.
Referrer-Policy
Define que informação de origem é partilhada entre páginas.
Permissions-Policy
Restringe acesso a APIs sensíveis do browser.
Headers de performance e SEO técnico
- Cache-Control: define TTL de conteúdo estático para acelerar carregamento recorrente.
- ETag e Last-Modified: permitem respostas 304 e reduzem tráfego desnecessário.
- Content-Encoding: confirma compressão Brotli/Gzip ativa.
- Vary: evita cache incorreta em cenários com idioma/dispositivo.
Como configurar headers nos principais servidores web
A forma de adicionar ou corrigir headers HTTP depende da tecnologia do servidor. Em Nginx, os headers são definidos com a diretiva add_header dentro do bloco server ou location, usando sempre o parâmetro always para garantir que o header é enviado também em respostas de erro (4xx, 5xx).
Em Apache, o módulo mod_headers permite definir headers no ficheiro de configuração ou via .htaccess com a diretiva Header always set. Em Node.js com Express, a biblioteca helmet automatiza a configuração das principais headers de segurança com defaults alinhados com as boas práticas atuais. Serviços de proxy como Cloudflare permitem também adicionar headers via regras de transformação sem alterar o servidor de origem.
- Nginx:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; - Apache:
Header always set X-Content-Type-Options "nosniff" - Express.js:
app.use(helmet())— activa automaticamente os principais headers de segurança - Cloudflare: regras de transformação de response headers sem necessidade de aceder ao servidor de origem
Perguntas frequentes sobre HTTP headers
Porque é que alguns headers não aparecem nos resultados?
Esta ferramenta faz um pedido HEAD do browser, sujeito a restrições CORS. Muitos servidores bloqueiam pedidos cross-origin ou não expõem todos os headers desta forma. Para uma auditoria completa, use as ferramentas de desenvolvimento do browser (Network > Headers) ou serviços como securityheaders.com que fazem o pedido a partir de um servidor externo.
O que é o Content-Security-Policy e como configuro?
O CSP define uma lista de origens permitidas para scripts, estilos, imagens e outros recursos carregados pelo browser. Por exemplo, 'script-src self' permite apenas scripts do mesmo domínio. É uma das proteções mais eficazes contra ataques XSS. Comece com um CSP permissivo e vá restringindo gradualmente enquanto monitoriza erros na consola.
O HSTS pode causar problemas se for mal configurado?
Sim. O HSTS instrui o browser a forçar HTTPS durante o período definido em max-age. Com um valor alto (ex: 31536000 = 1 ano), reverter para HTTP torna-se difícil pois os browsers já visitados continuarão a forçar HTTPS. Comece com max-age=300 (5 minutos) em testes e aumente gradualmente após confirmar que HTTPS está estável em produção.
Como obter uma avaliação completa da segurança de headers?
Para scoring detalhado com recomendações, use securityheaders.com que atribui uma nota de A+ a F com explicação de cada header em falta. O Mozilla Observatory complementa esta análise com auditoria de cookies, redirecionamentos e configurações TLS. Ambos os serviços são gratuitos e fazem os pedidos de origem externa.