Chaves de API expostas no navegador: como encontrar e corrigir no seu app

Para achar chaves de API expostas no seu app, abra o DevTools do navegador e procure no código carregado por trechos como sk-, sb_secret_ e service_role. Se aparecer uma chave secreta, a correção tem duas partes: mover a chamada para o servidor e trocar (rotacionar) a chave, porque a antiga já deve ser considerada vazada.

Todo app moderno conversa com outros serviços: o banco de dados, a IA que gera respostas, o meio de pagamento. Para cada conversa dessas existe uma chave de API, uma espécie de senha que diz "este app tem permissão para usar este serviço".

O problema começa quando uma chave que deveria ficar guardada vai parar no navegador do usuário. Em apps feitos com ferramentas de IA, como Lovable, Bolt, Cursor ou v0, isso é mais comum do que parece, porque o jeito mais rápido de "fazer funcionar" costuma ser colar a chave direto no código da tela.

Nem toda chave visível é um problema

Antes de qualquer coisa, uma distinção importante: existem chaves públicas e chaves secretas.

Chaves públicas foram feitas para ficar no navegador. Elas identificam o seu app, mas sozinhas não dão poder sobre os dados. Exemplos:

• A publishable key do Supabase (começa com sb_publishable_) ou a antiga anon key. Segundo a documentação do Supabase, ela pode ir para o navegador porque quem limita o que ela acessa é o RLS, as regras de acesso por linha do banco. Veja como conferir o RLS no Supabase.
• A chave publicável do Stripe (começa com pk_).

Chaves secretas dão acesso total, ou cobram na sua conta a cada uso. Elas nunca devem aparecer no navegador. Exemplos:

• A secret key do Supabase (sb_secret_) ou a antiga service_role key. Ela ignora o RLS por completo, ou seja, lê e altera qualquer tabela.
• A chave da OpenAI ou de outro provedor de IA. Com ela, qualquer pessoa usa a IA e a conta vem para você.
• A secret key do Stripe (começa com sk_), que permite consultar e operar pagamentos da sua conta.

Um detalhe sobre o Supabase: as chaves antigas (anon e service_role) são longas e começam com eyJ. As duas têm formato parecido, então não dá para saber qual é qual só de olhar o início. Na dúvida, compare com o que aparece no painel em Settings > API Keys.

Isso não é só teoria. No caso CVE-2025-48757, que envolveu apps feitos no Lovable, o pesquisador listou entre os dados expostos chaves e tokens de serviços de terceiros, como Google Maps, Gemini e eBay.

Como procurar chaves de API expostas no seu próprio app

Faça isso apenas no app que é seu. Você precisa só de um navegador como Chrome ou Edge.

1. Abra o DevTools

Com o app aberto, aperte F12 (ou clique com o botão direito e escolha Inspecionar). Abre-se o painel de ferramentas do desenvolvedor.

2. Procure no código carregado (aba Sources)

Na aba Sources, use a busca em todos os arquivos (Ctrl+Shift+F no Windows/Linux ou Cmd+Option+F no Mac). Pesquise por trechos típicos de chave:

• sk- e sk_live (OpenAI e Stripe)
• sb_secret_ e service_role (Supabase)
• palavras como secret, apiKey, api_key, token

Se aparecer uma chave secreta, ela está no "bundle", o pacote de código que o navegador baixa. Qualquer visitante consegue ler o mesmo arquivo.

3. Observe as requisições (aba Network)

Na aba Network, recarregue a página e use o app normalmente: faça login, gere uma resposta da IA, inicie um pagamento. Clique nas requisições e veja os Headers. Se o seu navegador está chamando direto api.openai.com ou api.stripe.com com uma chave no cabeçalho Authorization, a chave secreta está no lado errado.

4. Confira o repositório

Se o código está no GitHub, verifique se o arquivo .env foi enviado junto e se ele está listado no .gitignore. Repositório público com .env é uma chave exposta, mesmo que o app em si esteja correto.

Atenção às variáveis "públicas"

Ferramentas como Vite e Next.js têm uma convenção: variáveis com prefixo VITE_ ou NEXT_PUBLIC_ são embutidas no código que vai para o navegador. É comum a IA criar algo como VITE_OPENAI_API_KEY. O nome já entrega o problema: essa chave vai para o público.

Como corrigir

1. Mova a chamada para o servidor

A chave secreta precisa morar num lugar que só você controla. Num app com Supabase, a opção natural são as Edge Functions: pequenas funções que rodam no servidor. O navegador chama a sua função, e a função, com a chave guardada, chama a OpenAI ou o Stripe.

As chaves ficam na página de Edge Function Secrets do painel, ou são enviadas pela linha de comando com supabase secrets set, e a função as lê com Deno.env.get('NOME_DA_CHAVE') (documentação). A função também deve conferir quem está chamando (usuário logado, limites de uso), senão ela vira uma porta aberta para a mesma chave.

2. Rotacione a chave

Tirar a chave do código não basta. Se ela já foi publicada, considere-a comprometida: alguém pode ter copiado. Gere uma chave nova, troque em todos os lugares em que o app a usa, confirme que tudo funciona e só então apague ou desative a antiga. O Supabase descreve exatamente essa sequência para as próprias chaves, em Settings > API Keys. OpenAI e Stripe têm telas equivalentes nos seus painéis.

3. Olhe a conta

Depois de rotacionar, confira o histórico de uso e cobrança do serviço. Um pico de consumo que você não reconhece é sinal de que a chave foi usada por terceiros.

4. Evite que volte

Peça à ferramenta de IA, de forma explícita, que chaves secretas fiquem só em funções de servidor. E repita a busca do DevTools a cada nova versão importante do app, junto com os outros itens do checklist de segurança para lançar um app feito com IA.

Quer uma revisão completa?

Chaves expostas costumam andar junto com outros pontos frágeis, como regras de banco permissivas e rotas sem login. Se você prefere ter certeza antes que alguém descubra por você, conheça o diagnóstico de segurança para apps feitos com IA da Prisma Digital: revisamos o código e a configuração do seu app e entregamos um relatório claro, com o que corrigir primeiro e como.