Segredos que viajam com o bundle: milhões de apps expõem tokens no navegador e como detê-lo

Os vazamentos de chaves e tokens de API deixaram de ser uma raridade. Nos últimos anos, vimos como segredos que deveriam permanecer em ambientes fechados acabam circulando em repositórios públicos, imagens de contêineres e, com crescente frequência, dentro do próprio código que é enviado para o navegador. Por que continuam a produzir estas fugas quando existem tantas ferramentas e práticas para evitá-las? Após investigar como funcionam as diferentes aproximações da detecção de segredos e desenvolver uma verificação específica para bundles de JavaScript, o resultado foi surpreendente: ao analisar milhões de aplicativos foram encontrados dezenas de milhares de tokens expostos, muitos deles ativos e com permissões poderosas.

Os métodos clássicos para procurar segredos costumam ser apoiados em dois pilares: conhecer rotas habituais onde se podem deixar credenciais e aplicar padrões (normalmente expressões regulares) que identifiquem formatos de tokens conhecidos. Esta técnica, totalmente munificável, dá resultados úteis e rápidos, e é a que empregam muitos scanners de infra-estruturas. No entanto, tem um limite óbvio: se o motor de busca for formado por pedir a página raiz de um domínio e não reproduz os pedidos que faz um navegador - como a descarga de arquivos JavaScript -, muitos segredos nunca passam pela frente do detector. Um exemplo real de modelo que segue esse padrão pode ser visto nos repositórios do ProjectDiscovery para o Nuclei, onde são descritas verificações que inspecionam respostas directas a pedidos de HTTP específicos e actuam em conformidade: Modelo de Nuclei para tokens pessoais do GitLab.

Por outro lado, os testes dinâmicos de segurança (DAST) parecem, em teoria, uma boa opção para detectar segredos no front-end porque podem imitar a navegação real, rastrear a aplicação e compreender fluxos que requerem autenticação. Na prática, executar o DAST de forma exaustiva é mais caro e requer configuração avançada, por isso muitas organizações reservam um número reduzido de aplicações críticas. Além disso, nem todos os scanners DAST incorporam a mesma amplitude de padrões de detecção que ferramentas especializadas em busca de segredos.

A verificação estática do código (SAST) é outro elemento do arsenal: analisa o código fonte para prevenir que segredos cheguem à produção e é muito eficaz em muitos cenários. Mas os bundles de JavaScript usados em aplicações Web modernas, especialmente nas Single-Page Applications (SPA), podem ser construídos em etapas posteriores à análise estática ou com processos de build que injetam variáveis. Isso permite que novos segredos apareçam em artefatos compilados sem passar pelos controles que corre SAST, de modo que uma análise puramente estática do repositório nem sempre detecta o que finalmente se serve ao cliente.

Com estas limitações em mente, foi desenhada uma verificação orientada para examinar os bundles JavaScript baixados por um navegador. Ele pôs-se a trabalhar em escala: aproximadamente cinco milhões de aplicações foram rastreadas buscando padrões de tokens dentro dos arquivos servidos ao cliente. O volume de resultados superou os 100 MB de texto e mostrou mais de 42.000 credenciais coincidentes com 334 tipos diferentes de segredos. Nem todos os achados foram triados manualmente, mas entre as amostras verificadas apareceram exposições de alto impacto que ilustram bem o problema.

Entre os casos mais graves foram detectados tokens para plataformas de repositórios de código. No total apareceram 688 tokens vinculados a serviços como GitHub e GitLab, e uma parte relevante ainda estava vigente, permitindo acesso a repositórios privados. Em uma instância concreta, um token pessoal do GitLab foi colocado embebido em um arquivo JavaScript, concedendo permissões amplas sobre a organização, incluindo segredos de pipelines e acessos que facilitam movimentos laterais para serviços como AWS ou acessos por SSH. A documentação oficial do GitLab sobre Tokens Pessoais é um bom ponto de referência para entender os riscos que levam a expor: GitLab — Personal access tokens. Do mesmo modo, o GitHub mantém guias sobre a criação e gestão de tokens que convém conhecer: GitHub — Personal access tokens.

Outra exposição notável afetou chaves da API de ferramentas de gestão de projetos. Foram localizados tokens de Linear inseridos em código de front-end que permitiam ler tickets, projetos internos e links para integrações que, por sua vez, poderiam dar acesso a outros ativos e serviços. Para além destes exemplos, a exploração encontrou credenciais relacionadas com APIs de software de design assistido por computador, encurtar links com capacidade para criar e enumerar URLs, plataformas de e-mail marketing com acesso a listas e campanhas, webhooks de plataformas de bate-papo e automação - entre os quais centenas de endpoints ativos do Slack, Microsoft Teams, Discord e Zapier -, conversores de PDF e ferramentas de inteligência comercial que expunham bases de dados de contatos. Esses achados confirmam que a superfície de risco não se limita a poucos fornecedores, mas abrange uma grande variedade de integrações e serviços.

Que lições práticas derivam de tudo isto? Em primeiro lugar, as medidas de "shift-left" — analizar e prevenir desde as primeiras etapas do desenvolvimento — permanecem fundamentais. Ferramentas de SAST, scanners de repositórios, e plugins IDE detectam muitas más práticas antes que o código saia do ambiente de desenvolvimento. No entanto, não bastam por si só: qualquer segredo introduzido em fases de build ou durante a configuração de implantação pode contornar esses controles e terminar empacotado em um bundle servido ao navegador.

Por isso é essencial incorporar verificações que reproduzem o comportamento real de um cliente web: baixar arquivos JS que a aplicação entrega, inspecioná-los em busca de padrões de tokens e validar a atividade das credenciais detectadas. Essa abordagem exige mecanismos que interpretem a mesma árvore de recursos que um navegador obtém ao carregar uma SPA e que, além disso, realizem verificações automatizadas para determinar se um token continua a ser válido. A comunidade de segurança e os guias de boas práticas recolhem recomendações para gerir segredos — por exemplo o OWASP Secret Management Cheat Sheet — que convém integrar com detecções em tempo de execução.

No que diz respeito à atenuação específica, as organizações devem evitar, na medida do possível, que qualquer credencial com permissões sensíveis chegue ao cliente. Em vez disso, as aplicações devem delegar chamadas a serviços em servidores controlados, empregar proxys que ocultem chaves, usar tokens de curta vida e aplicar o princípio de menor privilégio. Além disso, ativar e complementar a digitalização de segredos que oferecem fornecedores como o GitHub —ver seu serviço de detecção de segredos — ajuda a interceptar vazamentos no código e nos artefatos publicados: GitHub — Secret scanning.

O panorama evolui também pela automação crescente e o uso de código gerado por ferramentas de IA: se os pipelines automatizados não estiverem configurados para proteger segredos, o risco de introduzir credenciais em artefatos compilados aumentará. A solução passa por combinar cheques estáticos no fluxo de desenvolvimento, digitalização em repositório, controles durante a compilação e detecção dinâmica que simule a descarga e inspeção dos bundles que chegam ao navegador. Para aplicações SPA especificamente, isso implica incorporar spidering e download de recursos estáticos como parte do processo de segurança, em vez de simplesmente pedir apenas a página inicial.

Detectar e eliminar segredos expostos em bundles não é uma tarefa trivial, mas a evidência mostra que é imprescindível: quando se analisaram milhões de aplicações apareceram dezenas de milhares de tokens expostos e centenas de tipos diferentes de segredos. Adoptar uma estratégia multi-capa, atualizar processos de CI/CD para não injetar credenciais em artefatos públicos, e executar digitalização que reproduz a experiência real do navegador são passos necessários para reduzir significativamente este risco. Se você quer aprofundar as diferenças entre análise estática e dinâmica e entender melhor quando usar cada técnica, os recursos de OWASP sobre análise de segurança são um bom ponto de partida: OWASP — Source code analysis e OWASP — Dynamic analysis.

Em suma, o problema está claro: os segredos não deveriam viajar até o navegador, mas com os processos de build, implantação e automação atuais isso continua acontecendo. A resposta não é uma única ferramenta, mas sim uma combinação de boas práticas, controles no pipeline e detecção que inspecione exatamente o que o navegador descarrega. Só assim poderemos reduzir a probabilidade de um token comprometido ser a porta de entrada a ativos muito mais valiosos.