Analisador de stack técnica

Seu site já conta para todo mundo do que ele é feito.

Digite uma URL e a gente identifica o construtor, o framework, o banco de dados, o provedor de autenticação, a hospedagem e o servidor que ele publica sobre si mesmo, e depois roda as quatro verificações que só fazem sentido quando isso é conhecido. Nada aqui vem de sondagem: está tudo na resposta que os seus visitantes já recebem.

Cheque sites que você possui ou tem autorização para testar. Pedimos a página como um navegador pediria e lemos o que volta. Veja nossos termos.

O que isso verifica, e como é uma boa resposta

O que dá para ver, e por que isso é visível

Nada disso está escondido. Um framework se anuncia porque precisa: o Next.js carrega os bundles a partir de /_next/static/, o Vite gera um caminho de asset previsível, o Supabase é chamado numa URL de projeto que tem que estar no seu JavaScript para o browser conseguir alcançar, e um monte de servidor ainda manda um header Server com número de versão dentro. A gente lê a mesma página e os mesmos scripts que um browser lê, e compara o que voltou com uma tabela de marcadores. Não tem chute de caminho aqui, e não tem requisição que os seus próprios visitantes já não façam.

Um servidor de desenvolvimento que foi para produção

O achado mais forte desta página, e surpreendentemente comum. O dev server do Vite não é um servidor web: ele lê da pasta do projeto a cada requisição, compila na hora, e expõe uma rota /@fs/ que consegue sair da raiz do projeto. Ele existe para que salvar um arquivo atualize o browser, e nunca foi escrito para ficar exposto na internet. Ele chega em produção sempre do mesmo jeito: alguém roda npm run dev, aponta um túnel ou uma hospedagem para ele para mostrar a um colega, e aquilo vira o deploy. Se a página carrega /@vite/client, foi isso que aconteceu.

Um build de desenvolvimento onde deveria estar o de produção

React, Vue e Angular entregam dois builds cada um. O de desenvolvimento mantém os avisos, os nomes dos componentes e a checagem de tipos de propriedade; o de produção remove tudo isso. Servir o build de desenvolvimento não é um buraco por onde um atacante entra, mas é várias vezes mais JavaScript do que a página precisa, mensuravelmente mais lento de executar, e descreve a sua árvore de componentes para qualquer pessoa que abrir o devtools. A gente só faz essa pergunta depois de reconhecer um framework que tem dois builds para escolher, porque numa página estática não existe bundle de desenvolvimento e dizer que você passou seria não dizer nada.

Dados do servidor embutidos na página

O Next.js escreve tudo o que as suas props de servidor retornam dentro do HTML de cada página que renderiza, num bloco __NEXT_DATA__. É assim que o framework funciona e isso não é um defeito. O defeito é o erro fácil que mora ao lado: você busca um registro de usuário para mostrar um nome, retorna o registro inteiro, e agora o e-mail, o id interno e o papel estão no código-fonte da página para quem apertar view-source. A gente procura nomes de campo que parecem registro em vez de dado de exibição, e reporta só os nomes, nunca os valores. Esse aqui pode dar falso positivo, então exigimos dois antes de falar qualquer coisa, e escrevemos como algo para você olhar, não como algo para corrigir.

Software fora da janela de suporte

Quando dá para ler uma versão, comparamos com uma tabela pequena de datas de fim de vida: PHP, Apache, IIS, OpenSSL, jQuery, Bootstrap, AngularJS e Vue 2. Estar fora de suporte não quer dizer que o site foi invadido. Quer dizer que o motivo pelo qual você tem direito de se sentir seguro, o de que as correções continuam chegando, parou de valer numa data específica, e tudo o que foi descoberto desde então continua ali. Conferimos contra as datas que o próprio fornecedor publica, então você pode checar a nossa conta. O que não fazemos de propósito é citar um CVE. Isso exigiria uma base de vulnerabilidades e casamento de faixas de versão que não temos aqui, e um scanner que chuta bugs específicos é pior do que um que diz que a versão é velha e para por aí.

Por que nada disso entra na pontuação

Reconhecer WordPress não é um achado. Reconhecer PHP, Vercel ou Stripe também não. Um monte de ferramenta apresenta lista de tecnologia como se cada item fosse uma acusação, e esse é o jeito mais rápido de tornar um relatório pouco confiável: ele aponta coisas que não dá para corrigir e que não valeria a pena corrigir. O painel de stack desta página não custa nada para você. Só as quatro verificações acima produzem achado, e só quando de fato encontraram alguma coisa.

Como corrigir

Três correções, na ordem em que costumam ser necessárias: pare de publicar o dev server, pare de publicar os arquivos de mapa e o banner do framework, e pare de anunciar versões que você ainda não atualizou. A última é cosmética sozinha e vale fazer mesmo assim, porque é a diferença entre ser alvo específico e passar despercebido numa varredura.

Publique o build, não o dev server
# The dev server is not a web server. It reads from your project
# directory on every request and serves whatever it finds, which is
# why /@fs/ can walk outside the project root at all.

# Wrong, and the single most common way this happens:
npm run dev            # then a tunnel or a host pointed at :5173

# Right:
npm run build          # emits dist/
npm run preview        # serves dist/ locally, to check it first

# Then deploy dist/ as static files. On a host that runs a command
# for you, the build command is 'npm run build' and the publish
# directory is 'dist' (Vite) or 'build' (Create React App).
Desligue os source maps e o banner do framework
// vite.config.js  -- source maps off, which is the default but
// worth stating, because a debugging session that flipped it on
// is how most of them end up in production.
export default {
  build: { sourcemap: false },
};

// next.config.js
module.exports = {
  productionBrowserSourceMaps: false,
  // Also drops the "X-Powered-By: Next.js" banner, which is the
  // header that tells a scanner exactly which framework to target.
  poweredByHeader: false,
};
Pare de anunciar versões
# nginx: stop announcing the version. server_tokens off leaves
# "nginx" but removes the number, which is the part that tells
# someone which published bugs to try.
server_tokens off;

# Anything proxied from PHP, Express or Rails announces itself too:
proxy_hide_header X-Powered-By;
proxy_hide_header X-AspNet-Version;

# Caddy, equivalent:
#   header {
#       -Server
#       -X-Powered-By
#   }

# Express, at the top of the app:
#   app.disable("x-powered-by");

# This is cosmetic on its own. It does not patch anything, it just
# stops handing over the version. Upgrade as well.
O que esta ferramenta não consegue ver

Só conseguimos nomear o que o site publica. Uma stack que não anuncia nada é invisível para nós, e resultado vazio aqui quer dizer que não reconhecemos nada, não que não há nada a reconhecer. O contrário importa mais: uma tecnologia que nomeamos é uma tecnologia que avistamos, não uma que testamos. Ler Server: Apache/2.4.41 diz qual é a string de versão, não se ela está corrigida, e reconhecer Supabase não diz absolutamente nada sobre o seu row-level security estar ligado, que é a pergunta que de fato decide se os seus dados são legíveis. Essa precisa do código. Se você quer as verificações que dependem da stack e não só a stack, o scan de superfície completo roda todas juntas e pontua o resultado.

Analisar o código tambémGrátis para começar. Conecte um repositório e o primeiro scan roda em cerca de dois minutos.