// Segurança por ferramenta
Segurança para apps feitos no Lovable
Resposta rápida
O furo clássico de um app feito no Lovable não é exótico: é Row Level Security (RLS) desligado nas tabelas do Supabase. Sem RLS, a anon_key que fica no bundle do front deixa qualquer pessoa consultar a tabela direto, sem login, e baixar a lista inteira de usuários, pagamento e chave. Não precisa de credencial especial, só abrir o DevTools.
Isso não é teoria: a CVE-2025-48757 expôs mais de 170 apps feitos no Lovable exatamente por RLS ausente, e uma auditoria de 50 apps achou 89% com RLS desligado no Supabase. Se você subiu no Lovable e tem login ou cobrança, a primeira coisa a revisar é essa.
O que o Lovable costuma gerar errado
O Lovable entrega produto rápido em cima de Supabase, mas delega o controle de acesso pra você, e é aí que quebra. A arquitetura é client-driven: o browser fala direto com o Supabase, então quem protege o dado é a política RLS, não o código da tela.
| Furo | Por que acontece | Impacto |
|---|---|---|
| RLS desligado na tabela | Tabela criada sem policy fica pública via anon_key | Dump da tabela inteira sem login |
| anon_key tratada como segredo | Ela é pública por design, mas sem RLS vira chave-mestra | Leitura/escrita direta no banco |
| Storage bucket público | Bucket sem policy expõe upload de todos | Vazamento de arquivo/foto/documento |
| Regra de plano só no front | Checagem de acesso pago feita na tela, não no banco | Usuário comum acessa recurso pago |
Como a RET revisa um app feito no Lovable
A revisão não é rodar um scanner e mandar PDF. A RET abre os fluxos que tocam dado e dinheiro e testa o que a anon_key alcança de verdade: quais tabelas respondem sem login, quais buckets abrem, onde a regra de plano só existe no front. Cada achado vem com o passo pra reproduzir e a prioridade de correção.
Para a primeira passada sozinho, o Promptbook tem os prompts exatos pra você checar RLS, bucket e chave com a IA que já usa. Quando aparece sinal sério, o Risk Review lê de 1 a 3 fluxos e diz o que corrigir agora.
- Teste real do que a anon_key acessa sem autenticação.
- Mapa de tabela por tabela: RLS on/off e policy correta.
- Checagem de bucket de Storage e regra de plano no lugar certo (banco, não tela).
Você já pode estar exposto se
Alguns sinais valem uma revisão imediata, não uma nota mental pra depois. Se qualquer um bate com o seu app, trate como prioridade.
- Você criou tabela no Supabase pelo Lovable e nunca escreveu uma policy RLS.
- Seu app tem plano pago, mas a checagem de acesso está no componente da tela.
- Você tem upload de arquivo e nunca conferiu se o bucket é público.
- Um cliente B2B pediu prova de segurança e você não sabe o que a anon_key libera.
Perguntas frequentes
A anon_key do Supabase é um segredo?
Não, ela é pública por design e fica no front. O problema é que, sem RLS ligado e com policy correta em cada tabela, essa chave pública vira acesso direto ao banco. A proteção é a RLS, não esconder a chave.
Como sei se meu app Lovable tem RLS desligado?
Na prática, testando: uma consulta com a anon_key, sem login, que devolve linhas de uma tabela sensível prova que a RLS está off ou a policy está errada. É o primeiro teste que a RET faz, e o Promptbook te guia a fazer sozinho.
Isso é um problema do Lovable ou meu?
Dos dois. O Lovable acelera muito, mas delega o controle de acesso pra você por padrão. O app é seu, o dado é seu, então a policy correta é responsabilidade de quem publicou. A boa notícia é que corrigir RLS é rápido quando você sabe onde olhar.
Quem faz a revisão na RET?
Gabriel Lima Ferreira, founder e lead pentester. A revisão entra com domínio verificado, aceite dos termos e escopo autorizado, e devolve evidência reproduzível com prioridade de correção.