Scan de HTTP headers: o que a resposta do seu servidor instrui o navegador a fazer
Veja o que o seu servidor instrui o navegador a fazer: CSP, HSTS, CORS e os demais cabeçalhos de segurança, cada um avaliado pelo valor enviado. Resultado na tela e PDF completo.
O que um cabeçalho de segurança instrui, e como o scan lê a política
Toda resposta HTTP traz, antes do conteúdo, um conjunto de cabeçalhos. Parte deles descreve o conteúdo: tipo, tamanho, regras de cache. Outra parte instrui o navegador sobre o que ele pode fazer com a página: de quais origens carregar script e outros recursos, se a página pode ser exibida dentro de um iframe, se as próximas visitas devem usar HTTPS obrigatoriamente, quanto do endereço enviar a outros sites como referência.
Essas instruções são executadas pelo navegador do usuário, não pelo servidor. Por isso elas limitam o efeito de falhas na aplicação: um script injetado em uma página com Content-Security-Policy restritiva não é carregado, mesmo que a injeção exista. O cabeçalho não corrige a falha. Ele impede que a falha se converta em execução.
Como o scan lê. Ele requisita a página inicial por HTTP e por HTTPS, registra cada redirecionamento até a resposta final e lê os cabeçalhos dessa resposta e das intermediárias. Para cada política, avalia as diretivas. Uma Content-Security-Policy com unsafe-inline em script-src é registrada como presente e ineficaz. Um Strict-Transport-Security que só aparece na última resposta da cadeia é registrado como tardio, porque a primeira requisição já ocorreu sem proteção. Para CORS, envia requisições com o cabeçalho Origin variado e observa o valor devolvido em Access-Control-Allow-Origin.
A análise usa a mesma engine do cidguard. Cada achado sai com severidade, o valor lido na resposta e a instrução de correção. Os termos do resultado estão explicados no glossário.
Cada cabeçalho, e o que é avaliado nele
default-src, script-src, object-src, base-uri e frame-ancestors. Curingas e as palavras-chave unsafe-inline e unsafe-eval em script-src são registrados como enfraquecimento da política.max-age (mínimo de um ano), includeSubDomains e em qual resposta da cadeia de redirecionamentos o cabeçalho aparece.nosniff, que impede o navegador de reinterpretar o tipo do conteúdo declarado pelo servidor.Access-Control-Allow-Origin e Access-Control-Allow-Credentials devolvidos a requisições com origens de teste.Da primeira requisição ao relatório
- 01
Informe o domínio
Apenas o domínio. Sem conta, sem cartão e sem instalação.
- 02
O scan percorre a cadeia
Requisita a página inicial por HTTP e por HTTPS, segue cada redirecionamento e lê os cabeçalhos de todas as respostas.
- 03
A nota aparece na tela
Score de 0 a 100, calculado pela fórmula do produto, com os achados mais graves abertos.
- 04
O relatório segue por e‑mail
PDF completo com o valor lido em cada cabeçalho e a instrução de correção, enviado a um e‑mail do domínio analisado.
O cabeçalho só aparece na última resposta. A primeira visita ao domínio raiz ocorre sem a proteção, e é registrada como HSTS tardio.
Por que apenas e‑mail do domínio analisado. O relatório descreve fraquezas de um domínio específico. Entregá-lo a qualquer endereço permitiria que terceiros obtivessem esse levantamento sem relação com o domínio. Quem não tem e‑mail no domínio pode entrar em contato e receber o relatório após confirmar a relação com ele.
O que o scan faz no alvo
Requisitar a página inicial
Uma requisição por HTTP e uma por HTTPS à página inicial, como as de um navegador, para ler os cabeçalhos retornados.
Seguir a cadeia de redirecionamentos
Cada salto entre http e https e entre hosts é registrado, com os cabeçalhos de cada resposta intermediária.
Enviar requisições com origem de teste
Poucas requisições com valores diferentes no cabeçalho Origin, para observar o que o servidor devolve em Access-Control-Allow-Origin.
Avaliar a política, não a presença
Cada cabeçalho é lido pelo valor: diretivas, tempo de vida, cobertura de subdomínios e ordem na cadeia.
Sondar portas e serviços
Varredura de portas alcança infraestrutura que pode pertencer ao provedor, como acontece em PaaS e CDN. Esse tipo de teste exige autorização formal do responsável pelo ambiente.
Enumerar caminhos
Não há tentativa de descobrir rotas como /admin ou /.env por lista de palavras. Esse procedimento gera volume de requisições no alvo e só é executado com autorização.
Procurar falhas na aplicação
XSS, painéis expostos, chaves em arquivos JavaScript e source maps exigem requisições além da página inicial. Esses vetores fazem parte da análise completa da plataforma, com autorização.
Cobrir o inventário
O resultado cobre o domínio informado. Subdomínios, ambientes de homologação e serviços auxiliares ficam fora deste diagnóstico.
Perguntas frequentes
O que são cabeçalhos de segurança HTTP?
São cabeçalhos de resposta que instruem o navegador sobre o que a página pode fazer: de quais origens carregar script e outros recursos (Content-Security-Policy), se deve usar HTTPS nas próximas visitas (Strict-Transport-Security), se pode ser exibida em iframe (X-Frame-Options e frame-ancestors), se pode reinterpretar o tipo do conteúdo (X-Content-Type-Options), quanto da URL enviar como referência (Referrer-Policy) e quais APIs do navegador usar (Permissions-Policy). São configurados no servidor ou no CDN e executados no navegador do usuário.
Qual cabeçalho tem maior efeito?
Strict-Transport-Security e Content-Security-Policy. O primeiro faz o navegador usar HTTPS antes de qualquer requisição nas visitas seguintes, o que elimina a janela em que a primeira requisição por HTTP pode ser interceptada. O segundo limita de onde scripts podem ser carregados e executados, o que impede que uma injeção de conteúdo se converta em execução de código no navegador.
Tenho CSP configurado. Por que o scan aponta problema?
O scan avalia as diretivas, não a presença do cabeçalho. Uma política com unsafe-inline em script-src permite scripts embutidos na página, que é o vetor mais comum de XSS. Uma política com default-src * permite qualquer origem. Nos dois casos o cabeçalho existe, mas não restringe o que deveria restringir. O achado nomeia a diretiva e o valor que enfraquece a política.
O scan detecta CORS mal configurado?
Sim. Ele envia requisições com valores de Origin que o servidor não deveria aceitar e lê Access-Control-Allow-Origin e Access-Control-Allow-Credentials na resposta. Dois padrões são registrados como falha: o servidor refletir qualquer origem recebida, e a combinação de origem permissiva com Allow-Credentials igual a true, que permite a outro site fazer requisições autenticadas em nome do usuário.
Ele testa o redirecionamento de HTTP para HTTPS?
Sim. O scan requisita o domínio por HTTP e segue cada redirecionamento até a resposta final. Registra se a cadeia termina em HTTPS, se o domínio raiz e o www têm o mesmo comportamento e em qual resposta o Strict-Transport-Security aparece. Quando o cabeçalho só está na resposta final, a primeira requisição por HTTP já ocorreu sem proteção, e o achado é registrado como HSTS tardio.
Isso é o mesmo que um scanner de vulnerabilidades da aplicação?
Não. Este scan lê a configuração de resposta do servidor na página inicial. Encontrar XSS, painéis administrativos expostos, chaves em arquivos JavaScript ou source maps em produção exige requisições à aplicação além da página inicial, o que só é feito com autorização do responsável. Esses vetores fazem parte da análise completa da plataforma.
Por que a nota também considera TLS e e-mail?
O diagnóstico completo executa TLS, cabeçalhos HTTP e e-mail no domínio informado. Nesta página roda apenas o scan de cabeçalhos, e a nota reflete esse resultado. No diagnóstico completo, cada achado indica de qual verificação veio. É comum uma aplicação com cabeçalhos corretos estar em um domínio sem DMARC, que permite o envio de e-mail em nome da empresa.