Achou a chave secreta do Supabase no navegador? O que fazer na primeira hora

Você procurou service_role ou sb_secret_ no JavaScript do seu app, como na nossa verificação de 10 minutos no Supabase, e encontrou. Ou alguém mandou um e-mail avisando que encontrou. De um jeito ou de outro, a chave que ignora todas as regras de segurança do seu banco está pública.

É o erro mais grave com que um app feito com IA pode ir ao ar, e também um dos mais comuns. A boa notícia: a correção leva cerca de uma hora, se feita na ordem certa.

Por que essa chave é diferente #

O Supabase dá a todo projeto dois tipos de chave:

Com a chave secreta, um estranho não precisa achar uma brecha nas suas regras. Ele pode ler todas as tabelas, alterar qualquer linha, apagar dados e baixar arquivos do storage privado. As suas regras simplesmente não valem para ele.

Minutos 0–10: descubra qual chave vazou #

Abra Project Settings → API Keys no painel do Supabase e compare com o que você achou no navegador:

• Se começa com sb_secret_, é uma das novas chaves secretas. Dá para substituí-la sozinha, sem mexer em mais nada.
• Se é um token longo que começa com eyJ, é a antiga chave service_role. As chaves antigas não podem ser trocadas uma a uma, então o caminho é outro (abaixo).

Anote também onde a chave era usada: qual arquivo, qual funcionalidade. As ferramentas de IA costumam colocá-la no frontend porque algo falhou com a chave pública, normalmente uma regra de RLS que faltava, e o atalho foi a chave que ignora o RLS.

Minutos 10–30: substitua a chave #

Se for uma chave secreta nova (sb_secret_) #

1. Em API Keys, crie uma nova chave secreta e dê a ela um nome que diga onde será usada (por exemplo, edge-functions).
2. Coloque a chave nova em todo lugar onde o código de servidor precisa dela: secrets das Edge Functions, variáveis de ambiente da hospedagem, jobs em segundo plano.
3. Apague a chave vazada. As requisições que a usam passam a falhar na hora.

Se for a antiga chave service_role #

1. Crie uma chave publicável e uma chave secreta na página API Keys, se ainda não tiver.
2. Troque no frontend a chave anon pela publicável, e no código de servidor a service_role pela secreta. Publique.
3. Desative as chaves de API antigas na mesma página. Isso desliga ao mesmo tempo a anon e a service_role, e é por isso que o passo 2 vem antes. O Supabase permite reativá-las se você esqueceu algum cliente, então esse passo é reversível.

O Supabase está aposentando as chaves antigas de qualquer forma, então é um trabalho que você teria de fazer em breve.

Minutos 30–45: tire a chave do frontend de vez #

Substituir a chave estanca o vazamento; o código que dependia dela agora vai quebrar. Não resolva isso colocando a chave secreta nova de volta no navegador. Leve o trabalho para o servidor:

• Uma Edge Function do Supabase para a ação que precisava de acesso elevado (mandar um convite, gravar numa tabela de administração, chamar uma API paga). As Edge Functions leem as chaves secretas do projeto pelo ambiente, sem que você precise colá-las no código.
• Ou uma regra de RLS que permita exatamente o que a tela precisa. Muitas vezes a IA recorreu à chave secreta por causa de uma tabela com RLS ligado e nenhuma regra para o usuário logado. A regra certa torna a chave secreta desnecessária.

Depois, procure de novo no JavaScript gerado por sb_secret_, service_role e pelos primeiros caracteres da chave nova. O objetivo é zero resultados.

Minutos 45–60: veja o que aconteceu enquanto ela esteve exposta #

Você precisa saber se alguém usou a chave, e para isso precisa dos logs enquanto eles ainda existem.

• Em Logs, no painel, olhe as requisições à API no período de exposição: volumes fora do normal, requisições a tabelas que o app nunca lê, downloads em massa com select=*, exclusões que você não fez.
• Veja em Auth → Users se há contas que você não reconhece, e no storage se há arquivos que você não enviou.
• Se desconfiar de alterações nos dados, confira quais backups ou recuperação point-in-time o seu plano inclui antes de mudar mais qualquer coisa.

O tempo de retenção dos logs no Supabase depende do plano e pode ser curto, então faça isso hoje, não na semana que vem.

Garanta que isso não volte #

As ferramentas de IA repetem o que já viram no seu projeto. Alguns hábitos evitam um segundo vazamento:

• Guarde chaves secretas só em variáveis de ambiente do servidor, nunca em variáveis que o framework manda para o navegador (no Vite, tudo que começa com VITE_ vai parar no bundle; no Next.js, tudo que começa com NEXT_PUBLIC_).
• Use uma chave secreta por serviço, com o nome dele, para que um vazamento obrigue a trocar só uma.
• Antes de cada publicação, procure sb_secret_ e service_role no build. Leva segundos.
• Quando a IA sugerir a chave secreta para fazer um erro sumir, entenda isso como sinal de que falta uma regra de RLS.

Se preferir que alguém revise o app inteiro, com chaves, regras, storage e autenticação, o nosso Security Check gratuito olha o app de fora, sem alterar nada, e diz o que corrigir primeiro.