A plataforma é. A segurança do app gerado depende das regras do banco, das chaves e das permissões, que precisam ser revisadas antes de publicar.

A chave anon do Supabase no navegador é um problema?

Não por si só: ela foi feita para ser pública. Vira problema quando as tabelas não têm Row Level Security, porque aí essa chave lê tudo.

O scanner de segurança do Lovable basta?

Ajuda a achar configuração faltando, como tabela sem RLS. Não testa as regras do seu negócio, como um cliente ler o pedido de outro.

Guia · 7 min de leitura

O Lovable é seguro? O que verificar antes de publicar

A plataforma é segura. O app que você gerou nela pode não ser. Estas são as três falhas que mais aparecem em apps feitos com Lovable e como checar cada uma em poucos minutos.

Por Equipe Salak Security · Atualizado em 31 de outubro de 2026

A resposta curta

O Lovable, como plataforma, é seguro. Ele gera o código, publica o app e, na maioria dos projetos, conecta um banco Supabase. O que decide se os seus dados estão protegidos é o que foi configurado nesse banco e no código: quem pode ler cada tabela, quais chaves vão para o navegador e onde as permissões são conferidas.

Essas três decisões ficam com você, e são exatamente as que a IA mais erra quando ninguém pede explicitamente. Em 2025, uma falha catalogada como CVE-2025-48757 registrou apps feitos no Lovable expondo dados justamente por regras de acesso insuficientes no banco.

O que a plataforma protege e o que fica com você

A plataforma cuida da infraestrutura em que o app roda, do HTTPS, do login com Supabase Auth e das atualizações dela mesma.
Fica com você o que é específico do seu app: as políticas de acesso de cada tabela, as chaves de serviços pagos, as regras do negócio (quem vê o quê) e o que acontece quando alguém chama a API sem passar pela tela.

Falha 1: tabela sem Row Level Security

Todo app com Supabase envia para o navegador a URL do projeto e a chave pública (anon ou publishable). Isso é normal. O que impede essa chave de ler qualquer tabela é o Row Level Security (RLS), que define, linha a linha, quem pode ler e alterar. Tabela sem RLS, com a chave pública, é tabela aberta para a internet.

Como checar. No painel do Supabase, abra o SQL Editor e rode:

select c.relname as tabela, c.relrowsecurity as rls_ligado
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r'
order by 2, 1;

Toda linha com rls_ligado = false precisa ser corrigida antes de publicar. Depois, faça o teste que importa: pegue a URL e a chave pública que o seu app usa e tente ler a tabela sem login.

curl "https://SEU-PROJETO.supabase.co/rest/v1/clientes?select=*" \
  -H "apikey: SUA_CHAVE_PUBLICA"

A resposta certa é uma lista vazia ou um erro. Se vierem registros, qualquer pessoa consegue fazer o mesmo. O guia de RLS no Supabase mostra como escrever as políticas.

Falha 2: chave secreta no navegador

Para fazer uma função "funcionar logo", a IA às vezes coloca no front-end uma chave que nunca deveria sair do servidor: a service_role do Supabase, que ignora todas as políticas, ou a chave da OpenAI, do Stripe ou do serviço de e-mail. Tudo que está no código do navegador pode ser lido por qualquer visitante.

Como checar. Abra o app publicado, pressione F12, vá em Sources (ou Fontes) e use a busca em todos os arquivos (Ctrl+Shift+F ou Cmd+Option+F) por: service_role, sk-, sk_live, secret. Qualquer resultado é crítico.

Apagar não basta. Se uma chave secreta já foi publicada, considere que alguém a copiou: revogue no painel do serviço e gere outra. Depois, mova a chamada para uma Edge Function. O guia de chave exposta no frontend explica o passo a passo.

Falha 3: permissão que só existe na tela

O botão "Excluir usuário" só aparece para administradores. Mas a chamada que ele faz ao banco funciona para qualquer usuário logado. Esconder o botão não é proteger: quem abre o DevTools vê a chamada e repete.

Como checar. Crie dois usuários de teste, um comum e um administrador. Logado como administrador, abra a aba Network, faça a ação e copie a requisição (botão direito, Copy as cURL). Agora troque o token pelo do usuário comum e execute. Se funcionar, a permissão está só na tela.

A mesma lógica vale para dados de outro cliente: troque o ID na requisição (pedido 1042 por 1043) e veja se o banco devolve o que não é seu.

Outras falhas comuns

Buckets públicos no Storage com documentos que deveriam ser privados.
Edge Functions sem autenticação, que qualquer pessoa chama e que gastam a sua cota de API paga.
Cadastro aberto em apps que deveriam ser só para convidados.
Sem limite de tentativas em login, cupom ou envio de e-mail.
Views e funções que ignoram as políticas da tabela.

O scanner de segurança do Lovable resolve?

O Lovable passou a verificar a configuração do banco, como tabelas sem RLS, e a documentação recomenda revisar as políticas antes de publicar. É um bom primeiro filtro e vale rodar sempre.

O que ele não faz é testar as regras do seu negócio: se a política existe mas permite que um cliente leia o pedido de outro, se o administrador é conferido no servidor, se o fluxo de convite pode ser abusado. Isso exige alguém testando com usuários de cada perfil, como um atacante faria.

Antes de publicar

Rode a consulta de RLS e corrija toda tabela com false.
Teste a leitura de cada tabela sem login, com a chave pública.
Busque chaves secretas no pacote publicado.
Repita uma ação de administrador como usuário comum.
Troque IDs nas requisições e confira que só os seus dados voltam.