O Lovable transforma um prompt em um app full-stack publicado — normalmente React no front e Supabase para auth e dados. Essa mágica de ponta a ponta é por que ele é popular, e também por que seu risco de segurança se concentra em um lugar: o banco de dados.
O risco do Lovable em uma frase
Um app Lovable fala com o Supabase direto do navegador com a chave anon (pública). Isso é normal — desde que o Row Level Security esteja ativado com políticas corretas em cada tabela. Se não, qualquer um que abrir seu app lê e escreve todo o seu banco.
Pesquisadores de segurança reportaram publicamente grande número de apps feitos com Lovable expondo dados exatamente por essa brecha: RLS desligado e nada impedindo consultar cada linha. É o vazamento clássico do vibe coding.
O que verificar antes de lançar
- RLS em cada tabela. O mais importante. Tabelas novas vêm sem RLS. Ative e adicione políticas — veja o guia de Supabase RLS.
- Apenas a chave anon no frontend. A service-role ignora o RLS; nunca pode chegar ao navegador. Se chegou, rotacione já.
- Auth realmente obrigatória. Confirme que páginas e ações protegidas rejeitam usuários deslogados.
- Buckets de storage não públicos. Arquivos enviados não deveriam ser legíveis por qualquer um com a URL.
Como verificar rápido
Faça login como um usuário de teste e tente ler o registro de outro mudando o ID: se obtiver os dados dele, o RLS está quebrado. Ou automatize: o Nurbak testa seu app Lovable de fora e sinaliza tabelas publicamente legíveis, chaves expostas e headers faltando numa passada. Cole a URL, relatório em segundos.