Lovable é seguro? O que conferir antes de colocar dados reais no app

A resposta curta

O Lovable tem ferramentas de segurança boas e gratuitas. Elas não garantem que o seu app está seguro. A própria documentação diz que você é responsável por garantir que o app atenda aos requisitos de segurança do seu caso de uso, e que as ferramentas não substituem uma revisão completa (Lovable, Security).

Na prática, a pergunta mais útil é “o app que eu montei no Lovable está seguro?”. Isso depende de como as tabelas, as chaves e as rotas foram configuradas. Você consegue conferir quase tudo sozinho, em uma tarde.

O que o Lovable já verifica sozinho

São dois tipos de varredura (Lovable, Security):

• Quick scan: roda sozinho quando você publica. Olha o banco (tabelas sem RLS, regras que deixam todo mundo passar, proteção contra senha vazada desligada), as dependências e servidores MCP sem autenticação.
• Deep scan: lê todo o código. Procura controle de acesso falho, rotas sem login ou fáceis de abusar, injeção, segredos vazados, falhas em pagamento e em login e dados pessoais expostos. Não roda sozinho. Você precisa iniciar na tela de segurança do projeto ou no diálogo de publicação.

Os achados vêm marcados como Critical, Warning ou Info.

Por que o app pode vazar mesmo assim

O app feito no Lovable roda no navegador e fala direto com o banco (o Lovable Cloud é construído sobre o Supabase). Para isso, uma chave pública vai junto com o site. Isso é normal e está previsto: a chave publicável do Supabase é feita para ficar exposta (Supabase, API keys).

O que protege os dados é outra coisa: as regras de acesso por linha, o RLS. A documentação do Supabase é direta: uma tabela exposta sem RLS pode ser lida e alterada por qualquer papel que tenha permissão sobre ela (Supabase, Row Level Security). Ou seja, quem abre o site pode pegar a chave pública e ler a tabela inteira.

O mesmo vale para a lógica. Esconder um botão para quem não é administrador não impede ninguém de chamar a função que o botão chama. O Lovable avisa: use o estado de login do navegador só para controlar a tela, nunca para liberar acesso (Lovable, Security best practices). Controle de acesso quebrado é o primeiro item do OWASP Top 10 de 2025 (OWASP, A01:2025).

Checklist em 7 passos

Faça na ordem. Anote o que achar.

1. Rode o Deep scan e resolva os críticos

Abra a visão de segurança do projeto e inicie o Deep scan. Corrija tudo que vier como Critical antes de seguir. Depois, nas configurações do workspace, ligue a opção que bloqueia a publicação quando há problema crítico (Block publishing with critical issues), recomendada pelo Lovable (Lovable, Security).

2. Procure chaves secretas no site publicado

O Lovable diz que segredo guardado no código do front-end é visível para o usuário e deve ser considerado comprometido (Lovable, Security best practices). Para conferir:

1. Abra o seu site publicado no Chrome.
2. Aperte F12, vá em Sources e use a busca em todos os arquivos (Ctrl+Shift+F).
3. Procure por service_role, sb_secret_, secret, sk_live, sk_test e api_key.
4. Faça a mesma busca no repositório do GitHub, se ele estiver conectado.

A chave publicável do Supabase (sb_publishable_... ou a antiga anon) pode aparecer. Chave secreta (sb_secret_... ou a antiga service_role) não pode. Ela ignora todas as regras de RLS (Supabase, API keys). Chave secreta de pagamento, e-mail ou IA também não pode estar ali. O lugar delas é o recurso Secrets do Lovable, lida só em código de servidor.

3. Confira o RLS de cada tabela

No Lovable Cloud, as políticas ficam em More → Database → Manage → Policies. A tela é só de leitura: para mudar, você pede ao Lovable no chat (Lovable, Database access).

Se o app usa um Supabase seu, abra o Security Advisor no painel do Supabase. Três alertas importam aqui (Supabase, Database Advisors):

• 0013_rls_disabled_in_public: tabela pública com RLS desligado. Qualquer pessoa com a URL do projeto lê, edita e apaga as linhas. É o mais grave.
• 0007_policy_exists_rls_disabled: a política existe, mas o RLS está desligado, então ela não vale nada.
• 0010_security_definer_view: uma view que passa por cima do RLS.

Tabela nova também precisa de política. O Lovable recomenda checar isso sempre que o app ganha uma tabela (Lovable, Security best practices).

4. Teste como um estranho e como outro cliente

Ler a política não basta. Teste:

1. Abra o app numa aba anônima, sem login, e tente abrir as páginas internas pelo endereço direto.
2. Crie dois usuários de teste, A e B. Com A, crie um registro. Entre com B e tente ver, editar ou apagar o registro de A, inclusive trocando o ID no endereço.
3. Se B vê o dado de A, a política está errada. Pare e corrija antes de abrir para clientes.

O Lovable pede exatamente esse teste: confirmar que um usuário não vê os dados privados de outro (Lovable, Security best practices).

5. Confira as funções de servidor

Toda Edge Function ou rota de API tem que verificar quem chama e o que essa pessoa pode fazer. Isso vale também quando alguém chama a função direto, fora da tela do app (Lovable, Security best practices).

Cuidado redobrado com função que usa a chave secreta. Ela passa por cima do RLS, então a própria função tem que checar a permissão. Pagamento, cadastro e qualquer fluxo de várias etapas devem rodar no servidor.

6. Confira quem vê o projeto e o login

• App interno: visibilidade do workspace e login obrigatório.
• Confirme se o app está publicado como público de propósito.
• Ligue a proteção contra senha vazada no login por e-mail e senha.
• Revise quem tem acesso ao workspace.

Todos esses itens estão na doc do Lovable (Security e Security best practices).

7. Olhe a LGPD

Se o app guarda nome, e-mail, telefone ou CPF de alguém, ele trata dado pessoal. A LGPD obriga quem trata dados a adotar medidas de segurança contra acesso não autorizado (Lei 13.709/2018, art. 46). Na prática, os passos 2 a 6 são parte disso.

Tenha também uma política de privacidade que diga o que o app coleta e para quê. E saiba o prazo: se houver um incidente com risco ou dano relevante aos titulares, o controlador deve comunicar a ANPD e os titulares em três dias úteis (ANPD, Comunicação de incidente de segurança).

Achou uma chave vazada? Faça nesta ordem

Esta é a ordem do Supabase para chave secreta (Supabase, API keys), e a lógica serve para qualquer serviço:

1. Corrija a causa: tire a chave do código do front.
2. Crie uma chave nova no painel (no Supabase, em Settings → API Keys).
3. Troque a chave em todo lugar que a usa e confirme que tudo funciona.
4. Só então desative a chave antiga. Apagar uma chave secreta não tem volta.

Trocar a chave não apaga o que já foi lido com ela. Se a tabela estava aberta e tinha dados pessoais, avalie se houve incidente (passo 7).

Quando vale chamar alguém

O próprio Lovable sugere uma revisão profissional para apps com dados sensíveis ou funções críticas, e um teste de invasão antes de um lançamento grande (Lovable, Security). Vale pensar nisso quando:

• o app guarda dados pessoais de clientes, saúde ou dinheiro;
• você não consegue dizer quem pode ler cada tabela;
• o Deep scan aponta algo que você não sabe corrigir;
• o app vai ser divulgado e o número de usuários vai subir.

Nenhuma revisão zera o risco. Ela reduz o risco e mostra o que falta.

Peça o diagnóstico da Heartscale

A Heartscale cuida de apps feitos com IA. No diagnóstico, nossa equipe revisa chaves, RLS, rotas, funções de servidor, dependências e LGPD do seu app. Você recebe um relatório com os achados por gravidade e o preço de cada correção.

O diagnóstico custa R$ 398 e é abatido se você fechar a correção, a migração ou o plano mensal. Só trabalhamos em app de quem prova ser dono.

Pedir o diagnóstico do meu app