Lovable commitou um .env com chave do Supabase: veja quando isso é vazamento de verdade

Um post da comunidade DEV Community mostra o erro clássico de agentes como o Lovable: subir o .env no repositório. Na maioria dos casos a chave exposta já era pública por natureza; o que importa é saber qual chave pode ser vista por qualquer um e qual nunca pode sair do servidor.

Nota da redação: este artigo cita, além da fonte principal (post da DEV Community), dois comportamentos de produtos de terceiros que não constam nessa fonte nem em documentação oficial consultada: os prefixos NEXT_PUBLIC_ (Next.js), REACT_APP_ (Create React App) e PUBLIC_ (Astro), e o funcionamento do secret scanning/push protection do GitHub. São informações de conhecimento geral sobre essas ferramentas, mas não foram verificadas contra fonte primária nesta apuração. O núcleo do artigo, sobre o caso do Lovable e Supabase, está integralmente confirmado na fonte.

Um post da comunidade DEV Community mostra o erro clássico de agentes como o Lovable: subir o .env no repositório. Na maioria dos casos a chave exposta já era pública por natureza; o que importa é saber qual chave pode ser vista por qualquer um e qual nunca pode sair do servidor.

O susto de abrir o repositório e achar um .env

Um desenvolvedor que escreve na comunidade DEV Community sob o nome glitchbound descreve uma cena cada vez mais comum: você pede para o Lovable gerar um projeto, conecta no Supabase, e ao abrir o repositório no GitHub encontra um arquivo .env com o endereço do banco e uma chave longa. Todo guia de segurança manda nunca commitar .env. A reação natural é achar que vazou tudo.

Segundo o autor, que testou seis apps reais com uma ferramenta própria de verificação, essa alarme disparou errado em três dos seis casos. A primeira versão do checker marcava o .env commitado como o problema mais grave do projeto, e nas três vezes em que isso aconteceu, a chave exposta era inofensiva. O motivo está em como o Lovable nomeia essas variáveis.

Por que o prefixo já entrega a chave de qualquer jeito

Nos apps analisados, o .env trazia o endereço do projeto Supabase, uma variável chamada VITE_SUPABASE_PUBLISHABLE_KEY ou VITE_SUPABASE_ANON_KEY, e mais um dado público como o ID do projeto. O prefixo VITE_ é a pista central: o Vite (bundler usado pelo Lovable e por boa parte dos scaffolds React) copia toda variável com esse prefixo para dentro do JavaScript que roda no navegador.

Isso significa que qualquer visitante do site já recebe essa chave assim que a página carrega, bastando abrir o DevTools e procurar no bundle. Commitar o .env no Git não torna essa chave mais exposta do que ela já estava: o vazamento, se existir, já aconteceu no deploy, não no git push. O mesmo padrão existe em outros stacks: NEXT_PUBLIC_ no Next.js, REACT_APP_ no Create React App, PUBLIC_ no Astro.

A chave que realmente importa: publishable vs secret

O Supabase tem dois tipos de chave, e só um deles é perigoso fora do servidor:

• No padrão novo, sb_publishable_ é pública (o próprio guia do Supabase chama de segura para expor) e sb_secret_ é a chave secreta.
• No padrão antigo, ambas são strings longas começando com eyJ...; no painel do Supabase elas aparecem rotuladas como anon (pública) e service_role (secreta).

A chave service_role (ou sb_secret_) pula toda regra de acesso do banco. Ela é um vazamento real se aparecer em qualquer um destes lugares: dentro do .env do repositório, em qualquer variável com prefixo VITE_ (mesmo sem commit, porque ela vai para o bundle do navegador), ou em um commit antigo do histórico, já que apagar o arquivo não remove a entrada do git log. A mesma lógica vale para chave de outro serviço pago, como provedor de IA ou de e-mail.

O controle de verdade não é esconder a chave

A chave pública só é segura se as regras do banco estiverem no lugar. Ela abre a porta; quem decide o que o visitante pode fazer do lado de dentro é o Row Level Security (RLS). Uma tabela sem RLS configurado deixa a chave anon livre para ler e alterar dados, mesmo sendo "pública" por design.

O autor do post sugere um comando de duas linhas no SQL Editor do Supabase, que só lê o catálogo e não altera nada:

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by tablename;

Qualquer linha com rowsecurity = false é uma tabela sem regra nenhuma, e isso pesa muito mais do que o .env estar no GitHub.

Um relatório vazio não significa que o app está seguro.

An empty report does not mean the app is secure.glitchbound, autor do post na DEV Community

Se a chave secreta vazou, apagar o commit não resolve

Quando a chave que vazou é a service_role (ou sb_secret_), remover o arquivo do repositório não encerra o problema, porque ela continua válida até ser trocada. O fluxo correto é: tirar a chave do código primeiro (senão a nova vaza do mesmo jeito), gerar uma nova chave no painel do Supabase, apontar o servidor para ela, e desativar a antiga. O Supabase chama isso de rotacionar a chave.

Vale registrar também que o Supabase já avisou que vai descontinuar o padrão antigo de nomes (anon e service_role) até o fim de 2026, então migrar para sb_publishable_/sb_secret_ é uma mudança que vem de qualquer forma.

Checklist pro próximo prompt

Antes de aceitar o que o agente gerou, vale rodar estas checagens:

1. Procurar no .env por qualquer chave que NÃO tenha prefixo VITE_/NEXT_PUBLIC_/PUBLIC_ e que pareça uma credencial de servidor (sb_secret_, service_role, chave de API de LLM).
2. Rodar o select ... from pg_tables acima em todo projeto Supabase antes de considerar o backend pronto.
3. Ativar o secret scanning e o push protection do GitHub no repositório, que bloqueia o push quando reconhece o formato de uma chave conhecida.
4. Se uma chave secreta já foi commitada, tratar como vazada mesmo depois de apagar o arquivo: o histórico do Git guarda, e a correção é rotacionar, não deletar.

O erro do agente de código não é gerar o .env; é gerar o .env sem dizer qual das chaves ali dentro pode ser vista por qualquer um e qual não pode sair do servidor nunca.

Fonte: DEV Community — #vibecoding