Você percebeu, depois do commit ou do push, que um arquivo continha uma senha de banco, o token de uma API ou a chave de um serviço de IA. A sensação é de desespero, mas o que importa agora é a ordem das ações. Primeiro conter o dano, depois limpar.
Não é uma situação rara nem motivo de vergonha: acontece com iniciantes e com profissionais. Siga o roteiro.
Passo 1: revogue ou troque o segredo imediatamente
Esta é a ação mais importante e a primeira. Entre no painel do serviço que emitiu a chave e:
- apague ou desative a chave exposta;
- gere uma nova e atualize seu projeto com ela (num arquivo .env, não no código);
- se for senha de banco ou de e-mail, altere a senha;
- se for token de acesso, use a opção de revogar.
Faça isso antes de qualquer limpeza. Existem robôs que varrem o GitHub e outros sites atrás de chaves expostas e as testam em minutos. Enquanto a chave antiga estiver válida, ela é um risco, não importa o que você faça no repositório.
Passo 2: verifique se houve uso indevido
Depois de trocar, descubra se alguém usou a chave antiga:
- olhe o painel de uso e de cobrança do serviço, em busca de picos ou chamadas que você não fez;
- verifique os logs de acesso, quando houver;
- em banco de dados, confira se existem registros ou usuários novos que você não criou;
- em serviços de e-mail, veja se saíram mensagens que você não enviou.
Se encontrar atividade suspeita, entre em contato com o suporte do provedor e, se envolver dados de clientes, consulte vazamento de dados: o que fazer e LGPD para pequenas empresas.
Passo 3: remova o segredo do código atual
Edite o código para que ele leia o valor de uma variável de ambiente, e não esteja escrito no arquivo. O guia variáveis de ambiente e arquivo .env mostra como. Em seguida:
- adicione o arquivo .env ao .gitignore;
- crie um .env.example sem valores reais;
- faça um novo commit com a correção.
Esse commit protege o futuro, mas não apaga o segredo dos commits anteriores.
Passo 4: limpe o histórico do Git (opcional, mas recomendável)
Mesmo com a chave revogada, é boa prática remover o segredo do histórico, principalmente se o repositório é público. Isso reescreve o histórico e tem consequências:
- é preciso usar ferramentas próprias para isso. A ferramenta mais recomendada atualmente é a git-filter-repo, e o GitHub mantém um guia oficial sobre remoção de dados sensíveis de um repositório;
- depois de reescrever, é necessário forçar o envio, o que muda o histórico para todos que clonaram o projeto;
- forks e clones que já existem continuam com o conteúdo antigo.
Se o repositório é pequeno, está no início e só você trabalha nele, uma alternativa mais simples é criar um repositório novo a partir do código limpo, sem o histórico antigo. Em qualquer caso, a revogação do passo 1 é o que realmente protege você.
Se você ainda está aprendendo Git, o artigo Git e GitHub para iniciantes explica os conceitos de commit e histórico que ajudam a entender por que o segredo continua lá.
Passo 5: ative proteções para o futuro
Para reduzir a chance de repetir o erro:
- Use o .gitignore desde o primeiro commit, incluindo .env e arquivos de credenciais.
- Ative o escaneamento de segredos do GitHub, quando disponível no seu repositório. Ele alerta ao detectar chaves de provedores conhecidos. A disponibilidade e as regras variam conforme o tipo de repositório, então confira nas configurações de segurança.
- Revise o diff antes de cada commit. Um olhar rápido em “o que mudou” evita muita coisa.
- Use chaves com permissões mínimas e limites de gasto, quando o serviço oferece.
- Crie chaves diferentes para desenvolvimento e produção.
- Não cole segredos em chats de IA. Remova antes de pedir ajuda (veja privacidade nas conversas com IA).
O que ajuda a se acalmar
O desespero é compreensível, mas a maioria dos casos tem solução tranquila quando a chave é revogada logo. Alguns fatos ajudam a manter a calma:
- chaves de teste ou com limite de gasto causam pouco dano;
- muitos provedores bloqueiam ou avisam sozinhos quando detectam uma chave exposta;
- trocar a chave leva minutos, e o resto do trabalho pode ser feito com calma;
- a experiência costuma ensinar o hábito que evita a repetição.
O que não resolve é esperar para ver se alguém usou. Quanto mais tempo a chave antiga ficar válida, maior o risco. Anote o que aconteceu e o que mudou no processo, para que o erro vire aprendizado e não se repita.
Perguntas que ajudam a avaliar o tamanho do problema
- O repositório era público ou privado?
- Quanto tempo o segredo ficou exposto?
- A chave dá acesso a dinheiro, a dados de clientes ou só a um recurso de teste?
- Existem outros projetos que usam a mesma chave?
Quanto mais perigoso o acesso que a chave dá, mais rápido e mais completo precisa ser o seu trabalho. Para chaves de pagamento ou bancos com dados pessoais, além de revogar, avise quem for necessário e peça orientação a alguém da área de segurança ou jurídica.
Revogue primeiro, investigue depois e só então arrume o histórico. Essa ordem protege você mesmo quando o susto atrapalha o raciocínio.