Pular para o conteúdo
iseeu.cc

Cabeçalhos de segurança

Digite uma URL pública: o iseeu.cc a solicita a partir da rede da Cloudflare, segue os redirecionamentos, lista todos os cabeçalhos de resposta e dá uma nota de A+ a F aos que tratam de segurança.

O servidor do iseeu.cc solicita esta URL a partir da rede da Cloudflare. Só as portas 80 e 443, só hosts públicos (o próprio iseeu.cc não), 10 verificações por minuto; a URL não é armazenada.

Resposta curta

Uma página tira boa nota aqui quando envia HSTS com max-age de pelo menos 31.536.000 segundos (um ano, o mínimo aceito pela lista de preload do HSTS), uma Content-Security-Policy que restringe scripts, proteção contra ser exibida em frames, X-Content-Type-Options: nosniff, uma Referrer-Policy, uma Permissions-Policy e Cross-Origin-Opener-Policy. As sete verificações somam 100 pontos: 95 ou mais é A+, 85 é A, 70 é B, 55 é C, 40 é D, e qualquer valor menor é F.

Como é obtido

O servidor do iseeu.cc solicita a URL a partir da rede da Cloudflare (HEAD, ou GET se o HEAD for recusado), segue até cinco redirecionamentos conferindo cada salto contra endereços privados e reservados, e lê os cabeçalhos da resposta final sem baixar o corpo. Pontos: HSTS 25, CSP 20, frames (frame-ancestors da CSP ou X-Frame-Options) 15, nosniff 10, Referrer-Policy 10, Permissions-Policy 10, Cross-Origin-Opener-Policy 10. Configurações fracas ganham parte dos pontos: HSTS com menos de um ano fica com 12; uma CSP que permite scripts inline, eval ou origens de script curinga fica com 10.

Exemplo prático

Uma resposta com Strict-Transport-Security: max-age=31536000, Content-Security-Policy: default-src 'self'; frame-ancestors 'none', X-Content-Type-Options: nosniff e Referrer-Policy: no-referrer soma 25 + 20 + 15 + 10 + 10 = 80 pontos, nota B. Acrescentando uma Permissions-Policy e Cross-Origin-Opener-Policy: same-origin, chega a 100, A+.

Limites

  • A nota cobre só os cabeçalhos de resposta, não as configurações de TLS, o conteúdo dos cookies nem o código da página.
  • A requisição vem da Cloudflare, então o site pode responder de um jeito diferente do que responde ao seu navegador (desafios anti-bot, redirecionamentos por país).
  • O próprio iseeu.cc, endereços privados e portas diferentes de 80 e 443 não são verificados.

Fontes

Fontes conferidas em . Página atualizada em .

O que a ferramenta faz

Os cabeçalhos de resposta dizem ao navegador como tratar uma página: se deve exigir HTTPS, quais scripts podem rodar, quem pode exibi-la num frame. Esta verificação solicita a sua URL a partir do servidor do iseeu.cc na rede da Cloudflare (primeiro HEAD, e GET se o servidor recusar HEAD), descarta o corpo da resposta sem ler e dá nota aos cabeçalhos de segurança que voltam.

As verificações que entram na nota:

  • Strict-Transport-Security (HSTS). Diz ao navegador para usar só HTTPS com este host durante max-age segundos; assim, as visitas seguintes nunca enviam uma requisição HTTP simples que alguém numa rede Wi-Fi compartilhada poderia sequestrar. Um ano (31536000) ou mais conta como bom; includeSubDomains e preload são anotados. Enviado por HTTP simples, o cabeçalho é ignorado.
  • Content-Security-Policy (CSP). Lista de onde scripts e outros recursos podem vir. Se um atacante conseguir colocar uma tag <script> num campo de comentário, script-src 'self' impede que ela rode. 'unsafe-inline' ou 'unsafe-eval' em script-src enfraquecem essa proteção, porque aí o código inline injetado e o eval() rodam mesmo assim. frame-ancestors também é verificado.
  • Proteção contra clickjacking. Uma página hostil pode colocar a sua num frame transparente por cima de um botão falso, e o clique do visitante cai na sua página. X-Frame-Options: DENY ou SAMEORIGIN, ou a CSP frame-ancestors 'none' ou 'self', impedem isso; qualquer um dos dois atende a esta verificação.
  • X-Content-Type-Options: nosniff. Faz o navegador confiar no Content-Type declarado; assim, um arquivo de texto enviado por upload que contenha JavaScript, servido como text/plain, não pode ser executado por uma tag script.
  • Referrer-Policy. Com strict-origin-when-cross-origin, uma página em /reset?token=abc123 informa aos sites de terceiros só o esquema e o host no cabeçalho Referer, e não o token.
  • Permissions-Policy. Desliga recursos do navegador que a página não usa, para ela e para tudo o que ela incorpora. Com camera=(), microphone=(), geolocation=(), um frame de anúncio ou um script comprometido nem consegue pedir acesso a eles.
  • Cross-Origin-Opener-Policy (COOP). same-origin dá à sua página um grupo de contexto de navegação próprio; assim, uma janela de outro site que a abriu, ou que ela abriu, perde a referência e não consegue navegar nela nem sondá-la.

Mostrados, mas sem nota: valores de Server e X-Powered-By como Apache/2.4.41 (Ubuntu) ou PHP/7.4.3, que facilitam associar um site a vulnerabilidades conhecidas, e os atributos de cada Set-Cookie: Secure (só HTTPS), HttpOnly (invisível para o JavaScript) e SameSite (limita o envio em requisições entre sites).

A nota é um resumo heurístico, não uma auditoria de segurança. Cabeçalhos são uma camada; eles não corrigem uma injeção de SQL nem um CMS desatualizado.

Como usar

  1. Digite uma URL pública completa, começando com http:// ou https://.
  2. Rode a verificação. Ela desiste depois de 5 segundos.
  3. Leia a cadeia de redirecionamentos. São seguidos até 5 redirecionamentos, e cada salto mostra o código de status e o Location.
  4. Leia o código de status final, a nota e a lista de cabeçalhos de resposta.

Só as portas 80 e 443 são permitidas. Endereços privados, de loopback, link-local, de CGNAT e outros reservados são recusados, assim como localhost e nomes terminados em .local ou .internal. O próprio iseeu.cc também é recusado, inclusive quando um redirecionamento termina aqui, porque a verificação chamaria o mesmo servidor; para ver os cabeçalhos deste site, use curl -sI https://iseeu.cc/. Cada endereço IP tem direito a 10 verificações por minuto. A URL não é armazenada nem registrada em log.

O destino vê uma requisição vinda da Cloudflare, e não de você; por isso, um desafio anti-bot, um redirecionamento por país ou um servidor que trata HEAD de forma diferente de GET podem mudar o resultado.

Casos de uso

  • Depois de um deploy. Confirme que uma mudança no proxy ou na CDN não derrubou nenhum cabeçalho, como o HSTS que some depois da troca de um balanceador de carga.
  • Redirecionamentos em ordem. Verifique se http:// chega a https:// em um único salto e se o domínio com www e o sem www terminam no mesmo endereço.
  • Avaliação de fornecedores. Antes de incorporar a página de login ou de pagamento de um fornecedor, veja se ela permite ser exibida em frame.
  • Versões expostas. Encontre um cabeçalho Server ou X-Powered-By que informe a versão exata.
  • Revisão de cookies. Garanta que os cookies de sessão tenham Secure, HttpOnly e SameSite antes que um auditor aponte o problema.
  • Implantação de CSP. Depois de sair do modo report-only, confirme que a política aplicada está no ar e sem 'unsafe-inline'.

Um bom conjunto para começar

Um ponto de partida razoável para um site que serve os próprios scripts e estilos:

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cross-Origin-Opener-Policy: same-origin

O X-Frame-Options repete o frame-ancestors para navegadores antigos. Esta CSP bloqueia scripts inline, manipuladores de evento inline como onclick e estilos inline, então teste antes de aplicar. Se as suas próprias páginas exibem o site em frame, use 'self' e SAMEORIGIN.

Implante a CSP no modo report-only

Envie a política como Content-Security-Policy-Report-Only e o navegador não bloqueia nada; ele registra as violações no console e num endpoint de relatórios que você configurar. Deixe rodar com o tráfego normal, corrija o que aparecer e depois renomeie o cabeçalho. Você também pode aplicar uma política mais frouxa e testar uma mais rígida ao mesmo tempo. Um cabeçalho report-only sozinho não protege ninguém.

Preload do HSTS é um compromisso

Adicionar preload e cadastrar o domínio o coloca numa lista embutida no Chrome e usada também pelo Firefox, Safari e Edge, e os navegadores passam a pular o HTTP simples já na primeira visita. A lista exige includeSubDomains e max-age de pelo menos um ano; por isso, todo subdomínio, até um host de intranet esquecido ou a página de administração de uma impressora, precisa servir HTTPS válido. Sair da lista é demorado, porque a remoção só chega às pessoas conforme elas atualizam o navegador. Comece com um max-age como 300, aumente quando nada quebrar e deixe o preload para o fim.

Esqueça o X-XSS-Protection

Os filtros de XSS dos navegadores que esse cabeçalho controlava não existem mais: o Chrome removeu o XSS Auditor em 2019, o Edge aposentou o filtro dele, o Firefox nunca teve um, e os filtros podiam ser explorados para desativar scripts escolhidos. Envie X-XSS-Protection: 0 ou nada, e confie na CSP.

Verificando com curl

curl -sI https://iseeu.cc/
curl -sIL http://iseeu.cc/
curl -s -D - -o /dev/null https://iseeu.cc/

O primeiro mostra os cabeçalhos de uma única resposta HEAD, incluindo os cabeçalhos do próprio redirecionamento, que a lista de saltos daqui deixa de fora. O segundo segue os redirecionamentos e mostra cada resposta. O terceiro envia GET e descarta o corpo, para servidores que tratam HEAD de forma diferente. Acrescente | grep -i strict-transport para isolar um cabeçalho; os nomes não diferenciam maiúsculas de minúsculas, e o HTTP/2 os envia em minúsculas.

Perguntas frequentes

Tirar A+ quer dizer que o meu site é seguro?

Não. A nota resume alguns cabeçalhos de resposta que dificultam certos ataques do lado do navegador. Ela não diz nada sobre atualizações, autenticação, controle de acesso, falhas de injeção ou a forma como os segredos são guardados. Um site pode tirar A+ e mesmo assim vazar dados por uma API mal feita, enquanto um site com nota mais baixa pode ser bem administrado. Encare a nota como uma olhada rápida em uma camada, não como uma auditoria.

Por que os cabeçalhos aqui são diferentes dos que aparecem no meu navegador?

A requisição sai da rede da Cloudflare, não do seu aparelho, e é uma requisição HEAD, a menos que o servidor recuse HEAD. Muitos sites mudam a resposta conforme o país, conforme a requisição pareça vir de um bot ou conforme o método usado. Um desafio anti-bot, um redirecionamento por país ou um framework que trata HEAD de forma separada geram cabeçalhos diferentes. Rode o curl na sua própria máquina para comparar.

Dá para verificar um servidor da minha rede de casa ou do escritório?

Não. O verificador só se conecta nas portas 80 e 443 e recusa endereços privados, de loopback, link-local e de CGNAT, outras faixas reservadas e nomes como localhost ou terminados em .local ou .internal. Isso impede que ele seja usado para alcançar máquinas atrás do firewall de outra pessoa. Para um host interno, rode curl -I numa máquina dessa rede.

A URL que eu verifico fica registrada em algum lugar?

A URL não é armazenada nem registrada em log. O iseeu.cc não guarda registros de endereços IP nem de consultas, não tem banco de dados de visitantes e não usa cookies. O site verificado recebe, sim, uma requisição, mas ela chega da rede da Cloudflare, e não do seu endereço IP.

Configurações de segurança numa meta tag do HTML aparecem no resultado?

Não. O verificador lê apenas os cabeçalhos de resposta e descarta o corpo sem ler, então uma política numa tag meta http-equiv nunca é vista. Os navegadores também limitam as meta tags: uma CSP entregue assim ignora frame-ancestors e não funciona no modo report-only, e HSTS e X-Frame-Options em meta tags são totalmente ignorados. Cabeçalhos HTTP de verdade são o lugar confiável para tudo isso.

E se houver muitos redirecionamentos ou o servidor for lento?

O verificador segue até 5 redirecionamentos, mostrando o código de status e o Location de cada salto, e desiste depois de 5 segundos. Uma cadeia que precisa de mais saltos do que isso geralmente indica erro de configuração, como http e https, ou o domínio com e sem www, mandando o visitante de um lado para o outro. Cada salto a mais também custa aos visitantes reais uma ida e volta antes de a página começar a carregar.

A nota considera apenas os cabeçalhos de resposta de uma requisição feita a partir de um único local. Use-a como ponto de partida para o trabalho, não como veredito sobre a segurança geral de um site.