Cabeçalhos de segurança HTTP
Verifique se o seu site tem configurados corretamente os cabeçalhos de segurança HTTP.
Como funciona a verificação de cabeçalhos
A ferramenta envia um pedido HTTPS GET normal ao URL que introduzir e lê os cabeçalhos da resposta - os mesmos cabeçalhos que qualquer browser recebe. Nada é analisado do corpo da página; os cabeçalhos de segurança vivem inteiramente na resposta HTTP.
Depois procuramos os cabeçalhos que controlam as proteções do lado do browser: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options e Referrer-Policy. Cada cabeçalho presente soma pontos e os ausentes são listados com uma explicação do risco que deixam em aberto.
Como a verificação segue os redirecionamentos, o resultado reflete o URL final. Se o seu site redireciona de HTTP para HTTPS ou do domínio raiz para www, os cabeçalhos que vê pertencem ao destino.
Como interpretar os resultados
A pontuação é uma orientação rápida, não uma certificação. O que importa na prática:
- HSTS - diz aos browsers para usarem sempre HTTPS no seu domínio. Um max-age de pelo menos meio ano é prática comum; adicione includeSubDomains apenas se todos os subdomínios servirem HTTPS.
- CSP - a defesa mais forte contra XSS, mas também a mais difícil de escrever. Mesmo uma política básica que restrinja as fontes de scripts é uma grande melhoria face a nenhuma.
- X-Content-Type-Options: nosniff e X-Frame-Options (ou a diretiva CSP frame-ancestors) - proteções baratas de uma linha contra MIME sniffing e clickjacking.
Problemas comuns
Cabeçalho configurado, mas reportado como ausente. Um reverse proxy ou CDN à frente da sua aplicação pode remover ou substituir cabeçalhos. Compare a resposta com curl -I diretamente contra a origem e contra o URL público para descobrir que camada o elimina.
CSP presente, mas ineficaz. O Content-Security-Policy-Report-Only regista as violações sem bloquear nada. É útil para testes, mas não oferece proteção - mude para o cabeçalho de aplicação efetiva quando o seu registo de relatórios estiver limpo.
Rotas diferentes devolvem cabeçalhos diferentes. Os cabeçalhos definidos no middleware da aplicação podem não se aplicar aos ficheiros estáticos servidos diretamente pelo servidor web, nem às páginas de erro. Teste também um URL de um recurso estático e uma página 404.
Perguntas frequentes
Que cabeçalhos de segurança deve ter qualquer site?
Uma base razoável: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy e proteção de frames via X-Frame-Options ou CSP frame-ancestors. As API beneficiam adicionalmente de Cache-Control: no-store em respostas sensíveis.
O cabeçalho X-XSS-Protection ainda é necessário?
Não. Os browsers modernos removeram o auditor XSS que ele controlava, e em browsers antigos o cabeçalho podia até introduzir vulnerabilidades. Use antes uma Content-Security-Policy rigorosa.
O HSTS protege a primeira visita?
Por si só não - o browser só aprende a regra na primeira resposta HTTPS. Para cobrir a primeira visita, submeta o seu domínio à lista de preload HSTS (hstspreload.org) e use a diretiva preload juntamente com includeSubDomains.
Pode um cabeçalho errado avariar o meu site?
Sim, dois casos clássicos: uma CSP demasiado rigorosa bloqueia os seus próprios scripts ou estilos inline, e o HSTS com includeSubDomains avaria qualquer subdomínio que ainda corra em HTTP simples. Implemente a CSP primeiro em modo report-only e comece o HSTS com um max-age curto.
Acompanhe alterações de cabeçalhos continuamente
O ePulz.io avisa-o quando um cabeçalho muda (por exemplo após uma implementação que removeu CSP por engano).
Começar com o ePulz.io →Acerca desta ferramenta
Os cabeçalhos de segurança dizem ao navegador como proteger os seus visitantes. Esta auditoria verifica se HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options e Referrer-Policy estão de facto presentes e classifica o resultado, para que detete falhas de clickjacking e MIME-sniffing após uma implementação.