Segurança no Lovable: 6 coisas para conferir antes de divulgar o seu app

Apps do Lovable usam o Supabase para banco, login e funções. O risco quase sempre está na RLS, nas chaves e nas funções abertas. Um roteiro em 6 passos.

Um app feito no Lovable costuma ter duas partes: o site (React) e o Supabase por trás, com o banco, o login e as Edge Functions. O site conversa com o banco direto do navegador, usando a chave pública do projeto. Isso é normal — e é justamente por isso que as regras do banco precisam estar certas.

1. RLS ligada em todas as tabelas

Sem RLS, qualquer visitante pega a chave pública do seu site e lê ou altera a tabela inteira pela API do Supabase. No SQL Editor do Supabase:

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

Toda tabela com rowsecurity = false está aberta.

2. Nenhuma política using (true) em dado pessoal

Quando algo quebra depois de ligar a RLS, a correção mais rápida é uma política using (true) — que reabre a tabela para todo mundo. Em clientes, pedidos, mensagens ou perfis, a política precisa filtrar por auth.uid().

3. A service_role só dentro das Edge Functions

A chave service_role (ou sb_secret_…) ignora a RLS. Ela pode existir nos segredos das Edge Functions, nunca no código do site. Busque por service_role nos arquivos do front: se aparecer, troque a chave no painel do Supabase e mova o uso para uma função.

4. Função que gasta dinheiro confere o login

Edge Function que chama a OpenAI, manda e-mail ou cobra alguma coisa precisa saber quem está chamando. Se o supabase/config.toml tiver verify_jwt = false para uma função, ela aceita chamada de qualquer pessoa — e aí a própria função tem que conferir o usuário antes de gastar.

const { data: { user } } = await supabase.auth.getUser(
  req.headers.get("Authorization")?.replace("Bearer ", "") ?? "",
);
if (!user) return new Response("faça login", { status: 401 });

5. Buckets do Storage com dono

Bucket público serve para imagem de produto e logo. Documento, comprovante e foto de usuário vão em bucket privado, com política que só libera o dono do arquivo.

6. Rode uma conferência no código

Ligue a sincronização com o GitHub no Lovable, baixe o repositório e rode, na pasta dele:

npx vibedefender

A análise acontece no seu computador: o código não é enviado a lugar nenhum. O resultado diz o que está aberto — e, no plano Pro, onde está cada problema e o texto pronto para colar no chat do Lovable e corrigir.

Dicas curtas de segurança para quem cria com IA: siga @npx_vibedefender no Instagram.