Apps feitos com IA
Seu app feito com IA está vazando dados?
Resposta curta: se o seu app do Lovable, Bolt ou v0 usa Supabase, faça quatro checagens antes de chegarem usuários de verdade: RLS em toda tabela, a chave service_role fora do navegador, links de login que só voltam para os seus domínios e um projeto de staging separado da produção.
Escrito por Matheus PavaneliPublicado em 10 de out. de 2026Revisado em 10 de out. de 20263 minFontes públicas, com link
Baixar em Markdown0 de 4 conferidas
Marque cada checagem conforme faz. Nada fica salvo.
Por que apps feitos com IA vazam
Ferramentas como Lovable, Bolt e v0 criam as tabelas do Supabase de que o app precisa, mas as regras que dizem quem pode ler cada linha são um passo à parte. A chave pública que todo navegador recebe consulta o banco direto, então uma tabela sem regra responde a qualquer um que tenha a chave, logado ou não.
O navegador do visitante
logado como voce@…, com a chave pública anon
Uma requisição
GET /rest/v1/profiles com essa chave
tabela profiles
1.240 linhas
- ana@… Ana Lima
- bo@… Bo Chen
- voce@… Você
- dev@… Dev Rao
1.240 linhas voltam para o navegador, de todo mundo.
Troque para ver o que a regra muda. As linhas são de exemplo.
fonte: NVD
1. RLS em toda tabela, ligada ao usuário
Uma tabela com RLS desligado, ou com política que libera todo mundo, pode ser lida inteira com a chave pública.
Confira você mesmo
No painel do Supabase, abra Authentication e depois Policies. Toda tabela do schema public precisa mostrar RLS ligado e uma política que compare uma coluna com auth.uid().
Corrija
Ligue o RLS em cada tabela e escreva uma política por ação. Para as linhas do próprio usuário:
alter table public.profiles enable row level security; create policy "own profile" on public.profiles for select using (auth.uid() = id);
2. A chave service_role nunca chega ao navegador
A chave service_role passa por cima de toda regra. Se vai no front-end, qualquer um copia do código da página.
Confira você mesmo
Abra o app no ar, veja o código-fonte e procure service_role nos scripts. Toda chave que aparecer precisa ter o papel anon.
Corrija
Deixe a service_role só no código do servidor ou nos segredos das edge functions, gere uma nova no painel e publique de novo.
3. Links de login só voltam para os seus domínios
Um curinga na lista de redirecionamento deixa um link de login forjado entregar a sessão para outro site.
Confira você mesmo
Authentication, depois URL Configuration. A lista deve ter o domínio de produção e os domínios exatos de preview que você usa, sem curinga.
Corrija
Troque os curingas por endereços exatos e deixe localhost só no projeto de desenvolvimento.
4. Um projeto de staging separado da produção
Testar contra o banco de produção quer dizer que um teste ou um prompt pode mudar dados de clientes reais.
Confira você mesmo
Confira para qual projeto do Supabase os builds de preview apontam. Se for o endereço de produção, os dois dividem os dados.
Corrija
Crie um segundo projeto para staging, copie o schema com as migrações e aponte os previews para ele.
Perguntas
A chave anon é segredo?
Não. Ela é pública de propósito e vai em toda página. Quem decide o que o visitante lê são as regras de cada tabela, não a chave.
O Lovable liga o RLS para mim?
A documentação do Lovable pede para revisar as políticas de cada tabela antes de publicar. Trate o que foi gerado como rascunho e confira tabela por tabela.
Dá para fazer as checagens sem mexer em código?
Três das quatro ficam no painel do Supabase. A da service_role só precisa do código-fonte da página no navegador.