Metodologia

A análise é passiva. Lemos o que o seu site já entrega a qualquer visitante: o HTML, os arquivos JavaScript que a própria página manda o navegador buscar, os cabeçalhos das respostas, e registros públicos de DNS e de certificados. Não tentamos adivinhar senha, não exploramos falha, não alteramos nada e não acessamos área logada.

O identificador que enviamos em toda requisição é WardenScan. Se você vir esse nome nos seus registros, era a análise que você pediu.

O motor trabalha em três camadas, e elas se distinguem por de quem é o sistema que responde.

Camada 1 — o seu site. Baixamos a página inicial e os arquivos JavaScript que ela declara, incluindo os módulos carregados sob demanda. É o mesmo tráfego de um visitante que abre o site e navega.

Camada 2 — endereços convencionais no seu domínio. Pedimos um conjunto fixo de caminhos que, por convenção, não deveriam estar públicos — arquivos de configuração e a pasta de controle de versão, por exemplo. São requisições ao seu servidor, em endereços que qualquer pessoa poderia tentar. A lista completa está no item 3.

Camada 3 — o backend que o seu site chama. O seu JavaScript diz, em texto aberto, para quais endereços ele manda o navegador buscar dados — pode ser um Supabase, um Firebase, um Strapi, um Hasura, ou uma API que você mesmo escreveu. Nessa camada perguntamos a esses endereços se eles respondem a quem não fez login, porque é isso que decide se os seus dados estão ao alcance de qualquer visitante. É a única camada que pode falar com um sistema hospedado fora do seu domínio, e por isso ela tem regras próprias, no item 4.

Cada análise executa estas verificações, em paralelo:

• JavaScript do aplicativo — leitura dos arquivos que a página declara, procurando chaves e credenciais deixadas no código, e dos mapas de código (.map) que o próprio site declarar.
• Arquivos públicos — robots.txt, security.txt, variantes de arquivo de configuração (.env e derivados), a pasta .git e nomes convencionais de chave de conta de serviço. Todos no seu domínio.
• Cabeçalhos de segurança — o que o seu servidor responde e o que deixa de responder.
• Política de CORS — quem o seu servidor autoriza a ler as suas respostas.
• TLS e certificado — validade, cadeia e configuração.
• DNS e proteção de e-mail — SPF, DKIM e DMARC, em consultas públicas de DNS.
• Subdomínios — pelos registros públicos de transparência de certificados. Não fazemos força bruta de nomes.
• Tecnologias e falhas conhecidas — identificação a partir do que o site declara, cruzada com falhas públicas.

Esta camada só alcança endereços que o seu próprio site chama — nós não adivinhamos endereço nenhum. E ela é opcional: se estiver desligada, dizemos no relatório que a configuração foi vista mas não foi testada, e nunca insinuamos que está correta.

Quando ligada, estas são todas as requisições que fazemos:

• Supabase e qualquer PostgREST: GET /rest/v1/ — o documento que o próprio serviço publica listando quais tabelas a API expõe (estrutura, não conteúdo) — e depois HEAD /rest/v1/<tabela>, no máximo quatro tabelas. O método HEAD não traz corpo: o servidor responde apenas se a leitura seria permitida e quantos registros existem. Nenhuma linha do seu banco atravessa a rede.
• Firebase: uma consulta de leitura mínima aos endereços que a configuração do seu site declara, com os parâmetros oficiais que retornam apenas nomes de chave e nenhum valor.
• Qualquer outro backend — Strapi, Directus, PocketBase, Hasura, Appwrite, Parse, ou uma API escrita por você: GETno endereço que o seu JavaScript chama, no máximo seis endereços, 8 KB por resposta. Aqui precisamos ler a resposta para saber se ela é uma lista de registros — e o que guardamos dela é apenas quantos registros vieram e os nomes dos campos. Nenhum valor é lido para o relatório, gravado no nosso banco ou impresso no PDF. Nome de campo é estrutura; valor é dado seu. Nessa mesma requisição enviamos um cabeçalho Origin inventado, para saber se o seu servidor autoriza qualquer site a ler a resposta — é a mesma pergunta que o navegador de um visitante faria, e não custa uma requisição a mais.
• Armazenamento de arquivos — S3, Google Cloud Storage, Azure Blob, R2: GET no índice do balde cujo endereço aparece no seu código, pedindo no máximo cinco entradas. Nunca baixamos um arquivo e nunca guardamos um nome de arquivo — nome de arquivo em balde costuma carregar dado de gente. O que fica registrado é a contagem e as extensões, que dizem o que está exposto sem expor de novo.

O que nunca fazemos nesta camada: gravar, alterar, apagar, ler o conteúdo de qualquer registro, ou usar qualquer chave que não seja a pública que o seu site já entrega ao navegador. Se o serviço responder com limite de requisições ou não responder a tempo, registramos como inconclusivo— nunca como “está protegido”.

Registro auditável. Cada requisição desta camada fica gravada nos nossos servidores com data, método, endereço, caminho, código de resposta e duração. Não guardamos corpo de resposta nem conteúdo nenhum. Você pode pedir esse registro e cruzar com os seus.

• Não tentamos autenticação, nem com credencial encontrada.
• Não exploramos falha, não injetamos nada, não fazemos varredura de portas.
• Não alteramos nem apagamos nada, em nenhum sistema.
• Não fazemos força bruta de nomes de arquivo ou de subdomínio.
• Não reproduzimos credencial encontrada por inteiro: no relatório ela aparece redigida, o suficiente para você reconhecê-la.

Uma análise sem achados não é um atestado. Significa que, no dia e na hora indicados, as verificações acima não localizaram nada visível de fora. O relatório sempre diz o que foi olhado e o que não foi.

A análise é uma fotografia. Um deploy feito depois dela pode mudar tudo o que ela mediu.