Checklist de segurança para apps do Lovable: seu app é seguro?
O Lovable, a plataforma, e o app que você construiu nela são protegidos separadamente. O Lovable faz varreduras em busca de erros comuns, mas seu app só é tão seguro quanto suas próprias regras de acesso, chaves e código de servidor. Verifique se a segurança em nível de linha está ativada em toda tabela exposta e corresponde a quem pode ver o quê, se nenhuma chave secreta chega ao navegador, se os pagamentos são confirmados no servidor e se alguém acompanha o app no ar.
- Por trás do CVE-2025-48757
- Segurança em nível de linha desativada, ou ampla demais
- Pode ir para o navegador
- Chave publicável (anon) do Supabase
- Nunca publique
- Chave service role ou outras chaves secretas
- Verifique de novo
- Depois de toda mudança que mexe em dados ou acessos
O Lovable é seguro, e isso deixa meu app seguro?
O Lovable diz que atende a requisitos de SOC 2 e GDPR e publica sua documentação de segurança no seu trust center. Isso cobre a plataforma do Lovable: a infraestrutura, os controles de acesso, a equipe. Não cobre as regras dentro do seu app, porque quem as escreveu foi você (com a ajuda do Lovable).
A varredura de segurança do Lovable roda uma verificação rápida toda vez que você publica: uma revisão do banco de dados, uma auditoria de dependências e uma verificação de servidor MCP. Uma varredura mais profunda, iniciada manualmente (ou agendada, para clientes do Lovable Enterprise), também revisa controle de acesso, endpoints sem autenticação, injeção, segredos vazados, pagamentos, autenticação e dados pessoais expostos. A própria documentação do Lovable é clara: essas ferramentas não podem garantir segurança completa. Trate a varredura como um detector de fumaça, não como uma vistoria.
O que foi o CVE-2025-48757, e ele afeta meu app?
O CVE-2025-48757, publicado em maio de 2025, descreve políticas de segurança em nível de linha insuficientes em sites gerados pelo Lovable até 15 de abril de 2025, que permitiam a atacantes não autenticados ler ou gravar tabelas do banco de dados. A National Vulnerability Database dos EUA o lista com nota CVSS 3.1 crítica de 9,3 e observa que o Lovable o contesta, sob o argumento de que cada cliente é responsável por proteger os dados do próprio app.
O pesquisador que o reportou, Matt Palmer, diz que analisou 1.645 projetos e encontrou 303 endpoints vulneráveis em 170 deles, e que o Lovable lançou sua varredura de segurança com o Lovable 2.0 em abril de 2025. Seja qual for sua opinião sobre a disputa, a lição prática é a mesma: se seu app foi gerado antes disso, ou se você mudou tabelas desde então, verifique suas políticas você mesmo. Uma política que existe não é o mesmo que uma política correta.
O que um checklist de segurança do Lovable deve cobrir?
| Verificação | Por que importa | Como testar |
|---|---|---|
| RLS ativado em toda tabela de um schema exposto | Sem ele, o Supabase deixa qualquer papel com permissão ler e gravar a tabela inteira | Rode o Security Advisor do Supabase; o lint 0013 (rls_disabled_in_public) aponta isso |
| Políticas correspondem às suas regras | Uma política como USING (true) passa na varredura e ainda deixa todo mundo passar | Entre como usuário A, peça as linhas do usuário B pela API e espere não receber nada |
| Tabelas com RLS mas sem política | Elas negam tudo, o que aparece como funcionalidade quebrada, não como vazamento | Lint 0008 do Advisor (rls_enabled_no_policy); depois escreva a política de que a funcionalidade precisa |
| Nenhuma chave secreta no navegador | A chave service role ignora todas as políticas de RLS | Procure sb_secret_ ou uma chave service_role antiga no JavaScript compilado; troque qualquer chave que já tenha sido publicada |
| Verificações no servidor em tudo o que custa dinheiro | O código do cliente pode ser editado por quem o está usando | Chame sua edge function diretamente com um preço ou plano alterado e espere uma recusa |
| Limite de requisições em cadastro, login e chamadas de IA | Requisições ilimitadas viram abuso ou uma conta surpresa | Na homologação, dispare 100 requisições rápidas por script e confirme que a maioria é recusada |
| Proteção contra senhas vazadas e MFA para administradores | Senhas reutilizadas de outros vazamentos são uma porta de entrada comum | Tente cadastrar uma senha que sabidamente vazou |
| Um log de auditoria e monitoramento de erros | Você não consegue investigar o que não registrou | Faça uma mudança administrativa na homologação e encontre-a no log |
Como corrigir erros de RLS do Supabase em um app do Lovable?
Os erros de RLS vêm em dois tipos opostos, e ajuda saber qual é o seu.
- Permissão negada (erro 42501 do Postgres, ou um resultado vazio). O RLS está ativado e nenhuma política permite a requisição. Isso é o RLS funcionando. Escreva a política mais restrita que faça a funcionalidade funcionar, por exemplo, linhas em que a coluna do dono é igual ao ID do usuário logado.
- Tudo funciona para todo mundo. O caso mais perigoso. Uma política como USING (true), ou o RLS desligado, deixa qualquer usuário passar. O advisor do Supabase aponta políticas permissivas (lint 0024, permissive_rls_policy) e políticas que existem com o RLS desativado (lint 0007, policy_exists_rls_disabled).
- Políticas que leem metadados do usuário. O Supabase alerta contra basear políticas em metadados que o próprio usuário pode editar (lint 0015, rls_references_user_metadata). Use em vez disso uma tabela que seu servidor controla, como uma tabela de membros da equipe.
Quando você pedir ao Lovable para corrigir uma política, rode de novo o teste com dois usuários depois. Um prompt que faz um erro sumir pode fazer isso ampliando o acesso, que é exatamente a falha que você está tentando evitar.
Quais chaves podem ficar expostas em um app do Lovable?
A documentação do Supabase diz que a chave publicável (anon) pode ser exposta, porque ela só alcança o que a segurança em nível de linha permite. Uma chave secreta, incluindo a chave service role, ignora todas as políticas de RLS e nunca deve ir para um navegador, um app publicado ou o controle de versão. O verbete do glossário sobre a chave anon e a chave service role explica a diferença. Segredos de terceiros, como as chaves da Stripe ou do provedor de e-mail, ficam nos segredos das edge functions, não no código do app. Veja gestão de segredos.
Com que frequência um app do Lovable no ar deve ser verificado de novo?
Depois de toda mudança que mexe em dados, acessos ou pagamentos, e periodicamente para todo o resto: dependências ganham novas vulnerabilidades, chaves devem ser trocadas e novas tabelas chegam com novas políticas. Por isso a segurança funciona melhor como hábito do que como auditoria. Nos nossos planos, verificações de segurança, revisão de código e testes de regressão rodam em toda mudança antes de ela chegar à produção, e um engenheiro diferente do autor a aprova.
Perguntas frequentes
O Lovable é seguro para um app de negócio de verdade?
O Lovable é um lugar razoável para construir e dar forma a um app, e ele faz varreduras em busca de erros de segurança comuns. Se o app final é seguro depende das próprias regras de acesso, chaves e código de servidor, que você deve verificar antes de chegarem usuários e dados reais. A documentação do Lovable diz que suas varreduras não podem garantir segurança completa.
A chave anon do Supabase no meu app do Lovable é um problema de segurança?
Não. O Supabase documenta a chave publicável (anon) como segura para expor, porque ela só alcança o que a segurança em nível de linha permite. Ela só vira problema quando o RLS está desativado ou amplo demais. A chave service role é diferente: ela ignora o RLS e nunca deve estar no navegador.
O CVE-2025-48757 ainda afeta apps do Lovable?
O CVE cobre sites gerados pelo Lovable até 15 de abril de 2025, e o Lovable o contesta. Desde então, o Lovable adicionou uma varredura de segurança. Qualquer app, antigo ou novo, ainda pode publicar uma política ampla demais, então teste suas próprias tabelas com duas contas de usuário em vez de confiar na data.
Quanto custa uma revisão de segurança de um app do Lovable?
Revisões pontuais são vendidas por muitos freelancers e empresas a preço fechado. Em um plano da Plutonapps, verificações de segurança e revisão de código rodam em toda mudança como parte do preço mensal, junto com construir, testar, lançar e operar o app. Planos e preços estão na nossa página de preços.
Posso fazer as verificações de segurança sozinho?
Sim. O Lovable roda sua varredura rápida quando você publica, o Security Advisor do Supabase está no painel do seu projeto, e o teste com dois usuários do checklist só precisa de duas contas de teste. O difícil de fazer sozinho é continuar fazendo isso em toda mudança, enquanto o app estiver no ar.
Do nosso trabalho
Termos nesta página
Comparações e guias relacionados
- App do Lovable não funciona em produção? Como deixá-lo pronto — Por que apps que funcionam na prévia quebram com usuários reais, as verificações que os deixam prontos para produção e quem os mantém funcionando.
- Como migrar do Lovable Cloud para o seu próprio Supabase — Lovable Cloud ou seu próprio Supabase, o que a exportação inclui e deixa para trás, e um plano de virada que mantém a produção funcionando.
- Como contratar um desenvolvedor Lovable (e quanto custa) — Freelancers, agências parceiras do Lovable e assinaturas de engenharia comparados em custo, escopo e quem opera o app depois.
- Planos e preços
Fontes
Todo fato externo desta página foi conferido com a fonte indicada em 30 September 2026. Preços e planos mudam; siga os links para os valores atuais.