Como evitar vazamento de secrets em bundles frontend antes do lançamento
Bundles frontend podem expor mais do que parece: chaves de API, endpoints internos e pistas da stack. Este guia mostra o que fundadores e builders devem verificar antes do lançamento para manter secrets privilegiados fora do navegador.
nota runtime
Use este guia antes do lançamento para confirmar que só identificadores públicos e de baixo risco chegam ao navegador, e que credenciais privilegiadas ficam no servidor.
Checklist rápido
- 01Procure no bundle de produção por strings que pareçam chaves de API, tokens, URLs privadas e hostnames internos.
- 02Confirme que credenciais privilegiadas vivem apenas em código server-side e nunca usam prefixos públicos de variáveis de ambiente.
- 03Revise cada valor de ambiente do frontend e classifique como identificador público, configuração ou secret privilegiado.
- 04Verifique se qualquer identificador visível no navegador tem permissões mínimas.
- 05Inspecione source maps, artefatos de build e arquivos estáticos em busca de comentários, dados de teste e endpoints de debug.
- 06Confira se caminhos de upload, caminhos de admin e nomes de serviços internos não aparecem em arquivos públicos.
- 07Rode um build final parecido com produção e revise o output mais uma vez antes de publicar.
- 08Ative monitoramento recorrente para secrets visíveis externamente no frontend, paths públicos, stack fingerprints e vulnerabilidades conhecidas.
Como secrets acabam dentro do bundle frontend
Bundle frontend é o conjunto de arquivos de JavaScript, estilos e recursos que o navegador recebe. Tudo o que vai nesse pacote pode ser visto pelo usuário, por ferramentas do próprio navegador ou por scanners automáticos. Por isso, um secret colocado no código do frontend deixa de ser privado. Os erros mais comuns são hardcode de tokens, cópia de valores de teste para produção e a suposição de que toda variável de ambiente é segura. Variáveis de ambiente não são secret automaticamente; credenciais privilegiadas precisam ficar em código server-side.
A regra mental mais segura é simples: se o navegador consegue ver, trate como público. Um identificador usado no browser pode ser aceitável quando é realmente público e tem permissões limitadas, como um identificador de mapas ou analytics com restrições. Já uma credencial privilegiada é outra coisa. Ela deve ficar no servidor, atrás de controle de acesso, e fora de qualquer bundle cliente, prefixo público de ambiente ou arquivo estático.
- ▸Tudo que vai para o navegador deve ser tratado como visível.
- ▸Identificadores públicos não são secrets, mas precisam ter permissões mínimas.
- ▸Credenciais privilegiadas pertencem ao código server-side, não ao client.
O que conferir no build antes de lançar
Comece pelo output do build de produção, não só pelo código-fonte. Gere o app exatamente como ele será publicado e inspecione os arquivos gerados em busca de strings sensíveis. Procure URLs privadas, hostnames internos, contas de teste, tokens e comentários que mencionem secrets. Vale também revisar source maps, que são arquivos que ajudam a ler código minificado. Se esses mapas estiverem públicos, podem revelar estrutura, nomes de variáveis e até valores que entraram por engano.
Depois, revise a configuração de ambiente. Separe o que é só do servidor do que pode aparecer no browser. Não coloque secret privilegiado em variável pensada para o cliente, mesmo que o nome pareça inofensivo. Se um valor precisa chegar ao navegador, confirme se ele é de fato público e se suas permissões são limitadas. Se a resposta for não, mantenha no servidor e envie para o frontend só o resultado mínimo necessário.
- ▸Inspecione arquivos gerados no build, não só o código-fonte.
- ▸Revise source maps e arquivos estáticos em busca de exposição acidental.
- ▸Separe configuração pública de credenciais server-only.
Como diminuir a chance de vazamento
Use uma regra simples: o frontend nunca deveria ter acesso direto a sistemas privilegiados. Em vez disso, faça o navegador conversar com seu backend, e o backend falar com serviços protegidos. Isso reduz os pontos onde secrets podem aparecer e facilita a revisão de acesso depois. Se uma biblioteca do lado do browser pedir um secret, pare e questione o desenho. Muitas vezes existe um padrão mais seguro usando uma rota no servidor.
Deixe o processo de release previsível e sem improviso. Tenha uma lista fixa para revisão de build, checagem de secrets e aprovação final. Remova logs de debug e dados de teste antes do deploy. Evite copiar secrets de produção para exemplos locais ou documentação. Se um valor é público, documente por que ele é público e o que ele pode fazer. Se é privilegiado, garanta que ele exista só onde o navegador não alcança.
- ▸Prefira acesso mediado pelo backend em vez de acesso direto pelo browser.
- ▸Remova logs de debug, dados de teste e valores temporários antes do release.
- ▸Documente por que qualquer identificador público é público e limitado.
O que fazer depois do lançamento
Lançar não encerra a verificação. Mudanças no frontend podem reintroduzir vazamento por meio de uma dependência nova, um hotfix rápido ou um valor de ambiente copiado errado. Mantenha monitoramento recorrente para secrets visíveis externamente no frontend, paths públicos, stack fingerprints e vulnerabilidades conhecidas. O monitoramento deve avisar quando o site público mudar de um jeito que possa expor estrutura interna ou valores sensíveis. Isso é especialmente útil quando o app recebe deploys frequentes ou tem várias pessoas editando o código.
Se aparecer algo suspeito, trate como problema de release, não só de segurança. Remova o valor do client code, refaça o build e confira o output público de novo. Se houver chance de uma credencial privilegiada ter sido exposta, tire-a imediatamente do código acessível pelo navegador e revise o acesso no servidor. Resposta rápida importa, mas o melhor cenário é prevenir: só identificadores públicos e de baixo risco devem ficar visíveis no browser.
- ▸Refaça a varredura após toda mudança relevante no frontend.
- ▸Observe novos paths públicos, stack fingerprints e vulnerabilidades conhecidas.
- ▸Trate exposição inesperada como defeito de release e corrija o caminho do build.
FAQ
Toda variável de ambiente é um secret?
Não. Variável de ambiente é só uma forma de guardar valores. Apenas credenciais privilegiadas precisam de proteção forte, e elas devem ficar em código server-side. Tudo que foi feito para o navegador deve ser tratado como público e limitado.
Posso colocar uma API key no frontend se eu rotacionar com frequência?
Não. Rotação não torna seguro um secret privilegiado exposto no navegador. Se o browser consegue ler, está exposto. Mantenha credenciais privilegiadas fora do client code e use acesso pelo servidor.
O que é seguro expor no navegador?
Só valores que são intencionalmente públicos e têm permissões mínimas, como um identificador público limitado. Mesmo assim, assuma que qualquer pessoa pode ver e mantenha a capacidade dele no menor nível possível.
Por que revisar source maps?
Source maps deixam o código empacotado mais fácil de ler. Se estiverem públicos, podem revelar estrutura de arquivos, nomes e valores que você não esperava publicar.