GUIAS

Chaves e segredos no código do cliente: como encontrar e corrigir

Por Guilherme Menezes. Última revisão: 6 de novembro de 2026.

Uma chave está exposta quando chega ao navegador ou fica em um repositório a que outras pessoas têm acesso. Em apps feitos com IA, o caso mais comum é uma variável com prefixo público, como NEXT_PUBLIC_ ou VITE_, guardando um segredo. Para verificar, procure as chaves no código enviado ao navegador e no histórico do repositório. Se encontrar uma, troque-a imediatamente.

Quais chaves podem ficar no navegador?

Depende da chave. Com o Supabase, por exemplo:

Podem ficar no navegador: a chave publishable e a antiga anon. Elas só alcançam o que as regras de RLS permitirem.
Nunca podem ficar no navegador: a chave secret e a antiga service_role. Elas ignoram o RLS, então quem as tiver pode ler e alterar todos os dados do projeto.

A regra geral para outros serviços é a mesma: se a documentação do serviço não disser que a chave é pública, trate-a como secreta. Isso inclui chaves de pagamentos, de envio de e-mail e de modelos de IA.

Por que o prefixo público é perigoso?

Os prefixos servem para enviar valores ao navegador:

Next.js: as variáveis com NEXT_PUBLIC_ são incluídas no JavaScript durante o build.
Vite: as variáveis com VITE_ ficam expostas no código do cliente, e a documentação avisa que não devem conter informação sensível.

O perigo é que a IA pode usar o prefixo só para fazer o código funcionar. A própria Vercel avisa que os modelos colocam credenciais e chaves de API nessas variáveis.

Como procuro chaves expostas?

1. Liste as variáveis públicas. No seu projeto, procure os prefixos:

grep -rnE "NEXT_PUBLIC_|VITE_" . --include=".env*" --exclude-dir=node_modules

Para cada variável, pergunte: este valor pode ser público? Nomes com SECRET, SERVICE_ROLE, PRIVATE ou API_KEY merecem atenção especial.

2. Veja o que o navegador recebe. Abra o app, abra as ferramentas de desenvolvedor e pesquise em todos os arquivos JavaScript por partes de cada chave. Confira também as requisições na aba de rede.

3. Procure no histórico do repositório. Apagar uma chave do código não a apaga do histórico:

git log -p -S "parte-da-chave" --all

Use um pedaço da chave, nunca a chave inteira, para não deixá-la no histórico do terminal.

Encontrei uma chave exposta. O que faço?

Troque a chave no serviço. Gere uma nova e desative a antiga. Só apagar do código não resolve, porque a antiga pode já ter sido copiada.
Mude o código. Passe a chamada para o servidor, em uma rota ou função, e use uma variável sem prefixo público.
Veja os logs do serviço. Procure usos que você não reconheça desde que a chave ficou exposta.
Avalie o impacto. Se a chave dava acesso a dados pessoais, leia o guia sobre LGPD e RGPD, porque você pode ter de comunicar a autoridade de proteção de dados.

Como evito que aconteça de novo?

Mantenha os arquivos .env fora do repositório, no .gitignore.
Revise todas as variáveis com prefixo público antes de cada lançamento.
Se você usa um editor com IA, não conte com arquivos ignorados como proteção total. A documentação do Cursor, por exemplo, avisa que as ferramentas de terminal e MCP do Agent não respeitam o .cursorignore.