O Que Fazer Quando Suas Chaves de API Acabam em um Repositório
Você fez push de código para o GitHub e percebeu segundos depois que sua chave de API foi junto. Talvez o GitHub tenha enviado um alerta. Talvez o GitGuardian tenha enviado um email. De qualquer forma, você está agora lidando com secrets expostos em aplicações frontend—e o relógio está correndo.
Aqui está o ponto crítico que a maioria dos desenvolvedores erra: remover a chave do seu último commit não resolve o problema. O histórico do Git preserva tudo. Forks podem já existir. Bots automatizados escaneiam repositórios públicos segundos após um push.
Este artigo cobre exatamente o que fazer quando chaves de API vazam no GitHub, como distinguir entre secrets verdadeiramente sensíveis e chaves de cliente públicas, e como prevenir que isso aconteça novamente.
Pontos-Chave
- Revogue e rotacione secrets expostos imediatamente—limpar o histórico do Git é secundário, pois a chave já está comprometida.
- Distinga entre chaves de cliente públicas (projetadas para uso no navegador) e secrets verdadeiros (credenciais privilegiadas que requerem ação urgente).
- O histórico do Git preserva tudo, então deletar um commit não remove o secret de forks, caches ou clones existentes.
- Habilite a proteção de push do GitHub para bloquear commits contendo secrets antes que cheguem ao seu repositório.
- Nunca armazene chaves privilegiadas em código frontend—use rotas de API server-side ou proxies de backend.
Primeiro, Entenda o Que Você Realmente Expôs
Nem todas as chaves carregam o mesmo risco. Antes de entrar em pânico, identifique que tipo de credencial vazou.
Chaves de cliente públicas são projetadas para serem visíveis. Chaves de API do Google Maps restritas a domínios específicos, tokens de analytics, ou chaves explicitamente prefixadas para uso client-side (como NEXT_PUBLIC_ no Next.js ou VITE_ no Vite) são feitas para serem incluídas em bundles de navegador. Estas ainda devem ter restrições de uso, mas a exposição não é catastrófica.
Secrets verdadeiros concedem acesso privilegiado: chaves secretas do Stripe, credenciais AWS, strings de conexão de banco de dados, ou qualquer chave que possa ler/escrever dados sensíveis ou gerar cobranças. Estas requerem ação imediata.
A distinção importa porque sua resposta deve corresponder à severidade.
Resposta Imediata: Revogue e Rotacione Primeiro
Quando você vazou um secret verdadeiro, a limpeza do histórico é secundária. Sua primeira prioridade é rotacionar chaves de API comprometidas.
Passo 1: Revogue a chave exposta imediatamente. Faça login no dashboard do seu provedor de API e delete ou desabilite a credencial comprometida. Não espere até ter limpado o histórico do Git—a chave já está comprometida.
Passo 2: Gere uma nova chave com escopo mínimo. Aplique o princípio do menor privilégio. Restrinja por IP, domínio ou endpoints de API específicos quando possível.
Passo 3: Atualize sua aplicação. Faça deploy da nova chave nos seus ambientes antes que sua aplicação quebre.
Alguns provedores de nuvem automaticamente desabilitam credenciais que detectam em repositórios públicos. Por exemplo, o Google Cloud pode automaticamente desabilitar chaves de conta de serviço expostas por padrão. Outros, incluindo a AWS, tipicamente notificam você mas não revogam chaves automaticamente de forma consistente. Todos esses provedores participam do programa de parceiros de escaneamento de secrets do GitHub. Não confie na automação—aja imediatamente de qualquer forma.
Por Que Deletar o Commit Não É Suficiente
O Git nunca esquece. Mesmo se você remover o secret do seu branch atual, ele vive em:
- Commits anteriores acessíveis via
git log - Forks criados antes da sua correção
- Clones existentes baixados por outros usuários ou bots
- Quaisquer mirrors feitos antes da remoção
É por isso que a revogação vem primeiro. A limpeza do histórico é contenção, não remediação.
Se você precisa limpar o histórico, ferramentas como git filter-repo ou BFG Repo-Cleaner podem ajudar. Mas entenda que se seu repositório foi público por qualquer período de tempo, assuma que o secret foi capturado.
Discover how at OpenReplay.com.
Escaneamento de Secrets e Proteção de Push do GitHub
O GitHub oferece proteção de primeira classe contra exatamente este problema. O escaneamento de secrets e proteção de push estão disponíveis para todos os repositórios públicos e para repositórios privados via GitHub Secret Protection (também incluído no GitHub Advanced Security).
O escaneamento de secrets detecta padrões conhecidos de credenciais no seu repositório e alerta você e/ou o provedor automaticamente.
A proteção de push vai além—ela bloqueia commits contendo secrets detectados antes que cheguem ao repositório. Este é o mecanismo de prevenção mais eficaz disponível.
Habilite ambos nas configurações do seu repositório em Settings → Code security and analysis, ou veja a documentação oficial sobre GitHub Secret Protection.
A Armadilha das Variáveis de Ambiente Frontend
Aqui está um erro que pega muitos desenvolvedores React, Vue e Next.js: variáveis de ambiente prefixadas para uso no cliente não são secrets.
Variáveis como REACT_APP_*, NEXT_PUBLIC_*, ou VITE_* são empacotadas diretamente no seu JavaScript. Qualquer pessoa pode abrir o DevTools e encontrá-las. Elas não estão ocultas—estão apenas organizadas.
Se uma chave concede acesso privilegiado, ela não pode viver em código frontend. Ponto final.
Estratégias de Prevenção para Equipes Frontend
Mantenha chaves privilegiadas server-side. Use rotas de API, funções serverless ou um proxy de backend. Seu frontend autentica usuários; seu backend guarda os secrets.
Habilite a proteção de push. Isso captura erros antes que se tornem incidentes.
Use hooks de pre-commit. Ferramentas como gitleaks ou detect-secrets escaneiam mudanças staged localmente.
Adicione escaneamento no CI. Execute detecção de secrets no seu pipeline como uma rede de segurança.
Restrinja chaves agressivamente. Mesmo chaves de cliente públicas devem ser limitadas por domínio, IP ou escopo de API.
Conclusão
Quando chaves de API vazam, velocidade importa mais que perfeição. Revogue primeiro, rotacione imediatamente, então limpe o histórico como um passo secundário. Não confunda chaves de cliente públicas com secrets verdadeiros, e nunca confie em variáveis de ambiente para esconder qualquer coisa em builds frontend.
Habilite a proteção de push do GitHub hoje. É a maneira mais fácil de garantir que este problema nunca aconteça novamente.
Perguntas Frequentes
Revogue ou desabilite a chave exposta imediatamente através do dashboard do seu provedor de API. Não espere para limpar seu histórico do Git primeiro. A chave já está comprometida no momento em que foi enviada para um repositório público, e bots automatizados podem capturá-la em segundos. Após a revogação, gere uma nova chave e atualize sua aplicação.
Não. O Git preserva todo o histórico, então o secret permanece acessível em commits anteriores, forks, clones existentes e quaisquer cópias feitas antes da sua correção. Deletar ou emendar o commit apenas o remove do topo do branch atual. Você deve revogar a chave independentemente de qualquer limpeza de histórico que realizar depois.
Não. Essas variáveis de ambiente prefixadas são empacotadas diretamente no seu JavaScript frontend e são visíveis para qualquer pessoa que abrir o DevTools do navegador. Elas são destinadas a valores de configuração públicos, não secrets. Qualquer chave que conceda acesso privilegiado deve ser armazenada server-side e acessada através de rotas de API ou proxies de backend.
Habilite a proteção de push do GitHub para bloquear commits contendo secrets detectados antes que cheguem ao seu repositório. Use hooks de pre-commit com ferramentas como gitleaks ou detect-secrets para escanear mudanças localmente. Adicione detecção de secrets ao seu pipeline de CI como uma rede de segurança adicional. Essas camadas trabalham juntas para capturar erros cedo.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
