Quais chaves de API são seguras no navegador e quais não são

Quem criou o app com Lovable, Bolt, v0, Cursor ou Replit uma hora passa por isto: alguém abre o site, aperta F12 e avisa que a sua chave de API está "exposta". É uma notícia assustadora sobre um app cujo código você não consegue ler.

Aqui está o que guia após guia erra: algumas dessas chaves deveriam mesmo estar ali. Tratar toda chave visível como um vazamento leva ou a um susto sem motivo ou, bem pior, a aprender a ignorar o aviso, e a ignorá-lo também no dia em que ele importa.

É ruim que minha chave de API esteja visível?

Normalmente não. Depende inteiramente de qual chave é.

Todo serviço que conversa com um navegador entrega dois tipos diferentes de credencial. Um é um endereço. O outro é o molho de chaves do prédio. Os dois se chamam "chave de API", e é daí que vem quase toda a confusão.

Um endereço pode ser publicado sem risco. Ele só diz a qual projeto um pedido pertence; a checagem de permissão acontece em outro lugar. Um molho de chaves não pode, porque ele é a checagem de permissão: quem o tiver faz tudo o que ele permite, de qualquer lugar.

Seu app precisa do endereço no navegador para funcionar. Ele nunca deveria precisar do molho de chaves ali.

Por que seu app manda chaves para o navegador

Porque o pedido sai do navegador do seu visitante, não do seu servidor.

Quando seu app carrega a lista de pedidos dos seus usuários, esse pedido sai direto do navegador do visitante para o seu provedor de banco de dados. Ele precisa dizer a qual projeto pertence, e esse identificador precisa estar na página, porque é de lá que o pedido é feito.

Não existe versão disso em que o identificador seja secreto. Ele chega a todo visitante por projeto. E é exatamente por isso que os provedores dividem as credenciais em duas: eles sabem que uma delas vai ser pública, então fizeram essa ser inofensiva.

A segurança não vem de esconder o endereço. Vem das regras que você define do outro lado: no caso do Supabase, o Row Level Security, que decide linha a linha quem pode ver o quê. São essas regras que valem a conferida, e ligá-las não é a mesma coisa que estar protegido.

As duas famílias de chave

O padrão vale além desses três. Se um provedor oferece só um tipo de chave, assuma que ela é secreta e que o lugar dela é um servidor.

Como diferenciar em 60 segundos

No Stripe, e na maioria dos provedores, basta o prefixo. pk_ é publicável e segura. sk_ é secreta e não é. Alguns provedores colocam _test_ ou _live_ no meio: uma chave de teste vazada é um problema bem menor do que uma de produção, mas troque as duas.

No Supabase depende de quão antigo é o seu projeto. O Supabase já emitiu dois formatos diferentes de chave, e os dois estão hoje em apps no ar.

Projetos novos: leia o prefixo, igual ao Stripe. sb_publishable_… é a que tem lugar no seu app. sb_secret_… é a que se troca hoje. Não há nada a decodificar: para que serve a chave está escrito na frente dela. O que mudou e o que isso significa para o seu app, caso você ainda não tenha esbarrado nelas.

Projetos antigos: é preciso olhar dentro da chave. O par original, anon e service_role, são JWTs: três blocos de rabisco separados por pontos, e o do meio é informação legível, não criptografia. Ali está o papel da chave em texto claro.

Em nenhum dos casos você precisa de ferramenta. Abra Settings → API Keys no painel do Supabase e ele diz qual é qual. Se preferir conferir a chave que você realmente achou no seu app, a parte do meio de uma chave antiga decodifica em algo assim.

{
  "iss": "supabase",
  "ref": "abcdefghij…",
  "role": "anon",          ← é esta palavra que importa
  "iat": 1750000000
}

"role": "anon" é a segura. "role": "service_role" é a que se troca hoje. Numa chave antiga essa única palavra é toda a diferença, e é por isso que um scanner que só procura textos com cara de chave devolve ruído em vez de resposta: ele não consegue dizer qual de duas chaves idênticas você publicou.

Se você prefere não vasculhar seu app chave por chave, nosso scan gratuito lê seu site no ar e diz quais dessas dá para ver de fora. Leva uns 20 segundos e não precisa de conta: escaneie seu app.

O que acontece de fato quando uma chave secreta vaza

Toda linha do seu banco de dados passa a poder ser lida e alterada por quem encontrou a chave, incluindo tabelas que você nunca expôs ao app e os dados pessoais dos seus usuários. O Row Level Security não se aplica a uma chave secreta do Supabase (sb_secret_…, ou service_role num projeto antigo). Esse é o propósito da chave.

O estrago também não é teórico. Normalmente ele aparece como uma mensagem de suporte sobre dados que mudaram sozinhos, ou como uma tabela que de repente está vazia.

Uma chave sk_live_ do Stripe vazada significa reembolsos, cobranças e cadastros de clientes. Uma chave vazada de um provedor de IA significa uma fatura, às vezes bem alta, chegando antes de alguém perceber.

Nada disso exige um atacante sofisticado. Há scanners automáticos varrendo sites públicos atrás exatamente desses textos, e eles não precisam saber quem você é para achar a sua.

Se quiser a versão específica da plataforma sobre o que conferir, temos um guia em linguagem simples para apps com Supabase.

O que fazer agora

Se preferir ir por uma lista, o checklist de segurança de 10 minutos cobre isso e as outras coisas que vale desligar num app recém-lançado.

E se um vazamento chegar a esvaziar uma tabela, recuperá-la depende inteiramente de o que você estava copiando.