Lista de verificação de segurança para apps do Lovable
O Lovable, a plataforma, e a app que construiu nela são protegidos separadamente. O Lovable procura erros comuns, mas a sua app só é tão segura quanto as suas próprias regras de acesso, chaves e código de servidor. Confirme que a segurança ao nível da linha está ativa em todas as tabelas expostas e corresponde a quem pode ver o quê, que nenhuma chave secreta chega ao navegador, que os pagamentos são confirmados no servidor e que alguém vigia a app em produção.
- Por trás da CVE-2025-48757
- Segurança ao nível da linha desligada, ou demasiado ampla
- Pode ser distribuída
- Chave publicável (anon) do Supabase
- Nunca distribuir
- Chave service role ou outras chaves secretas
- Voltar a verificar
- Depois de cada alteração que mexa em dados ou acessos
O Lovable é seguro, e isso torna a minha app segura?
O Lovable diz que cumpre requisitos SOC 2 e RGPD e publica a sua documentação de segurança no seu trust center. Isso cobre a plataforma do Lovable: a infraestrutura, os controlos de acesso, as pessoas. Não cobre as regras dentro da sua app, porque foi o próprio (com a ajuda do Lovable) que as escreveu.
A verificação de segurança do Lovable faz uma análise rápida sempre que publica: uma revisão da base de dados, uma auditoria de dependências e uma verificação do servidor MCP. Uma verificação mais profunda, iniciada à mão (ou agendada, para clientes Lovable Enterprise), revê também o controlo de acessos, endpoints sem autenticação, injeção, segredos expostos, pagamentos, autenticação e dados pessoais expostos. A própria documentação do Lovable é clara: estas ferramentas não podem garantir segurança total. Trate a verificação como um detetor de fumo, não como uma inspeção.
O que foi a CVE-2025-48757, e afeta a minha app?
A CVE-2025-48757, publicada em maio de 2025, descreve políticas de segurança ao nível da linha insuficientes em sites gerados pelo Lovable até 15 de abril de 2025, que permitiam a atacantes sem autenticação ler ou escrever em tabelas da base de dados. A National Vulnerability Database dos EUA lista-a com uma pontuação CVSS 3.1 crítica de 9,3 e nota que o Lovable a contesta, com o argumento de que cada cliente é responsável por proteger os dados da sua própria app.
O investigador que a reportou, Matt Palmer, diz que analisou 1645 projetos e encontrou 303 endpoints vulneráveis em 170 deles, e que o Lovable lançou a sua verificação de segurança com o Lovable 2.0 em abril de 2025. Seja qual for a sua opinião sobre a disputa, a lição prática é a mesma: se a sua app foi gerada antes disso, ou se alterou tabelas desde então, verifique as suas políticas. Uma política que existe não é o mesmo que uma política correta.
O que deve cobrir uma lista de verificação de segurança para o Lovable?
| Verificação | Porque importa | Como testar |
|---|---|---|
| RLS ativada em todas as tabelas de um esquema exposto | Sem ela, o Supabase deixa qualquer papel com permissões ler e escrever a tabela inteira | Corra o Security Advisor do Supabase; a regra 0013 (rls_disabled_in_public) assinala-o |
| As políticas correspondem às suas regras | Uma política como USING (true) passa numa verificação e continua a deixar passar toda a gente | Inicie sessão como utilizador A, peça as linhas do utilizador B através da API e espere não receber nada |
| Tabelas com RLS mas sem política | Recusam tudo, o que aparece como uma funcionalidade avariada, não como uma fuga | Regra 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 contorna todas as políticas RLS | Pesquise sb_secret_ ou uma chave service_role antiga no JavaScript compilado; rode qualquer chave que alguma vez tenha sido distribuída |
| Verificações no servidor para tudo o que custa dinheiro | O código do cliente pode ser editado por quem o usa | Chame a sua edge function diretamente com um preço ou plano alterado e espere uma recusa |
| Limitação de pedidos no registo, no início de sessão e nas chamadas de IA | Pedidos ilimitados transformam-se em abuso ou numa fatura inesperada | Contra o staging, envie 100 pedidos rápidos por script e confirme que a maioria é recusada |
| Proteção contra palavras-passe expostas e MFA para administradores | Palavras-passe reutilizadas de outras fugas são uma porta de entrada comum | Experimente uma palavra-passe que se sabe ter sido exposta no registo |
| Um registo de auditoria e monitorização de erros | Não pode investigar o que não registou | Faça uma alteração de administrador no staging e encontre-a no registo |
Como corrijo erros de RLS do Supabase numa app do Lovable?
Os erros de RLS são de dois tipos opostos, e ajuda saber qual tem.
- Permissão recusada (erro 42501 do Postgres, ou um resultado vazio). A RLS está ativa e nenhuma política permite o pedido. Isso é a RLS a funcionar. Escreva a política mais restrita que deixe a funcionalidade funcionar, por exemplo as linhas em que a coluna do dono é igual ao ID do utilizador com sessão iniciada.
- Tudo funciona para toda a gente. O caso mais perigoso. Uma política como USING (true), ou a RLS desligada, deixa passar qualquer utilizador. O advisor do Supabase assinala políticas permissivas (regra 0024, permissive_rls_policy) e políticas que existem com a RLS desligada (regra 0007, policy_exists_rls_disabled).
- Políticas que leem metadados do utilizador. O Supabase desaconselha basear políticas em metadados que o próprio utilizador pode editar (regra 0015, rls_references_user_metadata). Use antes uma tabela controlada pelo seu servidor, como uma tabela de membros de equipa.
Quando pedir ao Lovable para corrigir uma política, volte a fazer o teste com dois utilizadores a seguir. Um pedido que faz desaparecer um erro pode consegui-lo alargando o acesso, que é exatamente a falha que está a tentar evitar.
Que chaves podem ficar expostas numa app do Lovable?
A documentação do Supabase diz que a chave publicável (anon) pode ser exposta, porque só chega ao que a segurança ao nível da linha permite. Uma chave secreta, incluindo a chave service role, contorna todas as políticas RLS e nunca pode ir para um navegador, uma app distribuída ou o controlo de versões. A entrada do glossário sobre a chave anon e a chave service role explica a diferença. Os segredos de terceiros, como chaves da Stripe ou do fornecedor de e-mail, pertencem aos segredos das edge functions, não ao código da app. Veja gestão de segredos.
Com que frequência deve ser verificada uma app do Lovable em produção?
Depois de cada alteração que mexa em dados, acessos ou pagamentos, e de forma periódica para tudo o resto: as dependências ganham novas vulnerabilidades, as chaves devem ser rodadas e chegam novas tabelas com novas políticas. É por isso que a segurança funciona melhor como hábito do que como auditoria. Nos nossos planos, as verificações de segurança, a revisão de código e os testes de regressão correm em cada alteração antes de chegar à produção, e um engenheiro diferente do autor aprova-a.
Perguntas frequentes
O Lovable é seguro para uma app de negócio a sério?
O Lovable é um sítio razoável para construir e dar forma a uma app, e procura erros de segurança comuns. Se a app final é segura depende das suas próprias regras de acesso, chaves e código de servidor, que deve verificar antes de chegarem utilizadores e dados reais. A documentação do Lovable diz que as suas verificações não podem garantir segurança total.
A chave anon do Supabase na minha app do Lovable é um problema de segurança?
Não. O Supabase documenta a chave publicável (anon) como podendo ser exposta, porque só chega ao que a segurança ao nível da linha permite. Só se torna um problema quando a RLS está desligada ou é demasiado ampla. A chave service role é diferente: contorna a RLS e nunca pode estar no navegador.
A CVE-2025-48757 ainda afeta as apps do Lovable?
A CVE abrange sites gerados pelo Lovable até 15 de abril de 2025, e o Lovable contesta-a. Desde então, o Lovable acrescentou uma verificação de segurança. Qualquer app, antiga ou nova, pode continuar a ter uma política demasiado ampla, por isso teste as suas tabelas com duas contas de utilizador em vez de confiar na data.
Quanto custa uma revisão de segurança de uma app do Lovable?
Muitos freelancers e empresas vendem revisões pontuais a preço fixo. Num plano da Plutonapps, as verificações de segurança e a revisão de código correm em cada alteração como parte do preço mensal, a par da construção, dos testes, dos lançamentos e da operação da app. Os planos e os preços estão na nossa página de preços.
Posso fazer as verificações de segurança sozinho?
Sim. O Lovable corre a verificação rápida quando publica, o Security Advisor do Supabase está no painel do seu projeto e o teste com dois utilizadores da lista só precisa de duas contas de teste. O que é mais difícil de fazer sozinho é continuar a fazê-lo em cada alteração, enquanto a app estiver em produção.
Do nosso trabalho
Termos nesta página
Comparações e guias relacionados
- A sua app do Lovable não funciona em produção? Como a preparar — Porque é que apps que funcionam na pré-visualização falham com utilizadores reais, as verificações que as tornam prontas para produção e quem as mantém a funcionar.
- Como migrar do Lovable Cloud para o seu próprio Supabase — Lovable Cloud ou o seu próprio Supabase, o que a exportação inclui e deixa para trás, e um plano de migração que mantém a produção a funcionar.
- Como contratar um programador Lovable (e quanto custa) — Freelancers, agências parceiras do Lovable e subscrições de engenharia comparados em custo, âmbito e quem opera a app depois.
- Planos e preços
Fontes
Todos os factos externos desta página foram verificados face à fonte indicada a 30 September 2026. Os preços e os planos mudam; siga os links para os valores atuais.