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 browser ou fica num repositório a que outras pessoas têm acesso. Em apps feitas com IA, o caso mais comum é uma variável com prefixo público, como NEXT_PUBLIC_ ou VITE_, a guardar um segredo. Para verificar, procura as chaves no código enviado ao browser e no histórico do repositório. Se encontrares uma, roda-a de imediato.

Que chaves podem estar no browser?

Depende da chave. Com o Supabase, por exemplo:

Podem estar no browser: a chave publishable e a antiga anon. Só alcançam o que as regras de RLS permitirem.
Nunca podem estar no browser: a chave secret e a antiga service_role. Ignoram o RLS, por isso 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, trata-a como secreta. Isto inclui chaves de pagamentos, de envio de email e de modelos de IA.

Porque é que o prefixo público é perigoso?

Os prefixos servem para enviar valores para o browser:

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 nestas variáveis.

Como procuro chaves expostas?

1. Lista as variáveis públicas. No teu projeto, procura os prefixos:

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

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

2. Vê o que o browser recebe. Abre a app, abre as ferramentas de programador e pesquisa em todos os ficheiros JavaScript por partes de cada chave. Confere também os pedidos no separador de rede.

3. Procura 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

Usa um pedaço da chave, nunca a chave inteira, para não a deixar no histórico do terminal.

Encontrei uma chave exposta. O que faço?

Roda a chave no serviço. Gera uma nova e desativa a antiga. Só apagar do código não resolve, porque a antiga pode já ter sido copiada.
Muda o código. Passa a chamada para o servidor, numa rota ou função, e usa uma variável sem prefixo público.
Vê os registos do serviço. Procura utilizações que não reconheças desde que a chave ficou exposta.
Avalia o impacto. Se a chave dava acesso a dados pessoais, lê o guia sobre RGPD e LGPD, porque podes ter de notificar a autoridade de proteção de dados.

Como evito que volte a acontecer?

Mantém os ficheiros .env fora do repositório, no .gitignore.
Revê todas as variáveis com prefixo público antes de cada lançamento.
Se usas um editor com IA, não contes com ficheiros 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.