Guia · Lovable

O Lovable é seguro? O que fica exposto nos apps feitos com ele

A plataforma, sozinha, não é o que expõe os dados. O que expõe é a configuração do app que ela gera: principalmente as regras de acesso do banco de dados (o RLS do Supabase) e chaves secretas que acabam no código que vai para o navegador. As duas coisas dá para conferir em minutos.

Atualizado em 29/09/2026 · leitura de 7 min · por Warden

A resposta curta

O Lovable gera apps que funcionam — e funcionar é o que a IA persegue. O que decide se os dados ficam ao alcance de estranhos são duas coisas que só aparecem para quem olha de fora: quem pode ler cada tabela do banco e quais chaves vão parar no navegador. Por isso a pergunta útil não é “o Lovable é seguro?”, e sim “o meu app está expondo alguma coisa?”. Essa tem resposta verificável, e é o que este guia mostra.

O que aconteceu em 2025

Em março de 2025, o pesquisador Matt Palmer analisou 1.645 apps publicados com o Lovable e encontrou 303 pontos de acesso, em 170 apps — cerca de 10% —, com tabelas do banco de dados que respondiam a qualquer pessoa, sem login. O caso virou o registro público de vulnerabilidade CVE-2025-48757, divulgado em maio de 2025 (relato do pesquisador).

Desde então a plataforma incluiu verificações de segurança próprias. Mas a causa daquele caso vale para qualquer app que usa o Supabase: se uma tabela não tem regra de acesso, a chave pública do site basta para ler o que está nela.

O que mais aparece exposto

1. Tabelas sem regra de acesso (RLS)

O app conversa com o banco direto do navegador, usando uma chave que é pública de propósito. Quem separa o que cada pessoa pode ver é o Row Level Security. Tabela sem RLS — ou com uma regra que deixa todo mundo passar — entrega os dados a qualquer visitante. O passo a passo para conferir e fechar está no guia Supabase RLS.

2. A chave service_role no código do site

O Supabase tem duas chaves. A anon foi feita para ir no navegador. A service_role ignora todas as regras de acesso — é a chave-mestra do banco. Se ela aparecer no JavaScript do site, qualquer visitante pode ler, alterar e apagar tudo.

3. Chaves de outros serviços no front-end

OpenAI, Stripe, serviços de e-mail: quando a IA precisa fazer uma chamada funcionar, às vezes faz direto do navegador — e a chave secreta vai junto. Veja chave de API exposta: como descobrir e o que fazer.

4. Área de administrador escondida só na tela

Esconder o botão de “admin” de quem não é admin não impede ninguém de chamar a mesma operação direto no banco. A checagem de permissão precisa estar na regra do banco ou no servidor — não na interface.

Como conferir o seu app

1. Rode as verificações do próprio Lovable. A plataforma tem uma verificação rápida e uma profunda, que olham as regras do banco e o código do projeto (documentação oficial).
2. Confira as tabelas no painel do Supabase. O editor de tabelas sinaliza as que estão sem RLS, e as recomendações de segurança (Security Advisor) listam as tabelas públicas sem regra.
3. Olhe de fora. As verificações de dentro dizem como o projeto está configurado. Uma análise externa mostra o que um visitante qualquer consegue ver na versão publicada — que é o que importa se o app já está no ar.

Revise a segurança do banco de dados deste projeto:

1. Ative Row Level Security em todas as tabelas do schema public.
2. Nas tabelas com dados de usuário, crie políticas para que cada pessoa
   só consiga ler, criar, alterar e apagar as próprias linhas
   (user_id = auth.uid()).
3. Tabelas de conteúdo público (como um catálogo) podem permitir apenas
   leitura (SELECT) para todos — nunca INSERT, UPDATE ou DELETE sem login.
4. Confirme que a chave service_role não aparece em nenhum arquivo do
   front-end e que nenhuma chave secreta usa o prefixo VITE_.
5. No fim, liste cada tabela e a política que ficou valendo.