Seu MVP no Lovable funciona. Veja o que vai vazar

O Lovable entrega uma coisa que parecia impossível há pouco tempo: você descreve um produto e, em uma tarde, tem telas, login e banco de dados funcionando. Eu acho isso ótimo para validar ideia. O problema começa quando a gente confunde “funciona” com “pode ir para o ar com dado de gente real”.

Em 27 de fevereiro de 2026, o The Register publicou, em reportagem de Connor Jones, o caso de um app hospedado na Lovable e listado na vitrine da plataforma. O pesquisador Taimur Khan encontrou 16 falhas, seis críticas. O resultado: 18.697 registros de usuários expostos.

O que aconteceu com o app da vitrine da Lovable

O app tinha mais de 100 mil visualizações e cerca de 400 votos quando Khan começou a análise. Era usado por professores e alunos, incluindo pessoas da UC Berkeley e da UC Davis. Dos registros expostos, 14.928 eram e-mails únicos, 4.538 eram contas de estudantes e 870 usuários tinham dados pessoais completos à vista.

As falhas não eram sofisticadas:

• Banco sem regra de acesso por linha. O backend no Supabase não tinha row-level security nem controle por papel. Quem chegasse ao banco via tudo.
• Login com a lógica invertida. Uma função de autenticação bloqueava quem estava logado e deixava passar quem não estava. Nas palavras de Khan: “The guard blocks the people it should allow and allows the people it should block.”
• Poder de administrador para qualquer um. Um visitante sem login conseguia ver todos os usuários, mandar e-mails em massa, apagar contas e alterar notas.

A Lovable respondeu que leva esse tipo de achado “extremely seriously” e que agiu minutos depois de receber o relato formal. O CISO da empresa, Igor Andriushchenko, disse que todo projeto passa por uma varredura gratuita antes de publicar, mas que aplicar as recomendações é decisão do usuário. A empresa também afirmou que o projeto tinha código não gerado pela Lovable e que o banco vulnerável não era hospedado por ela.

Por que isso não é só um problema da Lovable

A mesma reportagem cita a Veracode: 45% do código gerado por IA continha falhas de segurança. Ou seja, o risco não está numa ferramenta específica. Está no jeito como a IA escreve código: ela entrega o caminho feliz, aquele em que o usuário faz exatamente o que você imaginou.

Segurança é justamente o caminho infeliz. É o que acontece quando alguém abre o app sem login, troca um número na URL ou chama a API direto. A IA não testa isso por conta própria. E a tela não mostra nada de errado, porque a tela está funcionando.

Checklist de segurança antes de lançar seu MVP

Esta é a lista que eu passaria em qualquer MVP feito com Lovable, Bolt, Replit ou similar antes de abrir para usuários reais. Ela não substitui uma revisão completa, mas pega o tipo de falha do caso acima.

Banco de dados

1. Row-level security ligada em todas as tabelas. No Supabase, uma tabela sem RLS fica acessível para quem tem a chave pública, que está no seu front-end.
2. Políticas escritas por papel. Aluno vê os próprios dados. Professor vê a turma. Admin vê tudo. Cada regra precisa existir no banco, não só na tela.
3. Teste com dois usuários. Crie duas contas e tente, com a segunda, ler ou editar dados da primeira.

Autenticação

4. Abra o app numa janela anônima. Navegue por todas as rotas sem login. Nada privado pode carregar.
5. Leia a função de proteção de rota. Confira se a condição está no sentido certo. O caso acima mostra que uma negação trocada basta.
6. Ações de admin conferidas no servidor. Esconder o botão não protege nada. A API precisa recusar o pedido.

Chaves e segredos

7. Nenhuma chave secreta no front-end. Chave de serviço do banco, de pagamento ou de e-mail fica só no servidor.
8. Variáveis de ambiente revisadas. Confira o que vai para o navegador e o que fica no servidor.

Dados e operação

9. Colete só o que precisa. Cada campo pessoal a mais é um campo a mais para vazar.
10. Limite de envio e de requisições. Uma rota que dispara e-mail sem limite vira ferramenta de spam.
11. Canal de contato para quem achar falha. Khan diz que seu primeiro relato foi fechado sem resposta. Tenha um e-mail claro e responda.
12. Rode a varredura da plataforma e aplique o que ela aponta. Ela existe. Ignorar a recomendação é a falha mais barata de evitar.

O que isso muda para você

Se o seu MVP foi feito em uma dessas ferramentas, ele provavelmente está mais perto do lançamento do que um projeto do zero. Isso é bom. Só não pule a etapa que a IA não faz sozinha.

No Studio, usamos Claude Code e Figma no design e no build, e todo sistema sai com um agente de IA que roda todo dia, aponta falhas, sugere melhorias e confere se os dados fazem sentido. [Descrição de como o Studio revisa segurança de MVPs herdados no diagnóstico: Leonel completar.]

Depois do diagnóstico, você recebe preço fechado e prazo escrito no contrato para levar o MVP ao ponto em que ele pode receber usuários reais. Se o seu app no Lovable já funciona e você quer ter certeza de que ele não vai vazar no primeiro mês, o resgate do Studio foi pensado para esse momento.