O Lovable e ferramentas do gênero fizeram algo genuinamente útil: transformaram “tenho uma ideia” em “tenho um app clicável” em dias. Para um founder validar hipótese, alinhar sócio ou mostrar a investidor, isso é ouro. O problema não é a ferramenta. O problema é a frase que aparece logo depois da demo funcionar: “está quase pronto, é só publicar”.
Não está. Entre o “quase pronto” e o “pronto para receber usuário real com dado de verdade” existe uma camada de engenharia que a geração automática não entrega — e que, quando ignorada, vira vazamento de dados na primeira semana. Este texto é o mapa dessa camada: o que auditar, por que cada item importa e qual é o fluxo de endurecimento que a Pixelize aplica para “terminar” um app do Lovable antes do go-live.
O que “quase pronto” esconde (definição)
Um app do Lovable “quase pronto” tem interface, fluxo e banco funcionando na demo — mas em geral falta o trabalho invisível que separa protótipo de produção: autorização no banco, validação no servidor, segredos protegidos e testes dos caminhos críticos.
A demo funciona porque roda no caminho feliz, com você de usuário e dados limpos. Produção é o oposto: usuários que você não conhece, dados sujos e alguém curioso trocando um id na URL só para ver o que acontece. A engenharia que falta é justamente a que lida com esse mundo real.
Onde os apps gerados quebram
RLS ausente ou incompleta (o clássico do Supabase)
O Lovable costuma usar Supabase como backend. E o ponto que mais assusta em auditoria é este: no Supabase, o front acessa o banco diretamente com uma chave pública (a anon key), e quem decide o que cada usuário pode ver é o Row Level Security (RLS) — regras de autorização no próprio banco. Como a documentação oficial do Supabase deixa claro, sem políticas de RLS ativas e corretas, uma tabela exposta pode ser lida (ou escrita) por qualquer um que tenha a chave pública — que está, por definição, no navegador de todo mundo.
Na prática, isso significa que um app gerado sem RLS bem configurada frequentemente permite baixar a tabela inteira de usuários, pedidos ou mensagens com uma requisição. Não é hipótese exótica: é a falha mais comum que encontramos.
Broken Object-Level Authorization (BOLA)
O segundo clássico. O app não confere se o usuário logado tem direito sobre o objeto que pediu. Você abre /pedido/1042, troca para /pedido/1043 e vê o pedido de outro cliente. A OWASP classifica isso como o risco número um de segurança de APIs — e é exatamente o tipo de verificação que um gerador de código pula, porque na demo só existe um usuário.
Chaves e segredos expostos
Chave de serviço, token de integração, credencial de pagamento acabando dentro do bundle que vai para o navegador, ou numa variável que o front consegue ler. Tudo que chega ao cliente é público na prática. Um segredo de servidor no front é um segredo vazado esperando ser encontrado.
Validação só no cliente
O app valida CPF, valor, permissão — tudo no navegador, e confia no resultado. Mas o navegador é o lado que o atacante controla. Validação de verdade acontece no servidor, antes de gravar no banco. Sem isso, dá para mandar qualquer coisa direto para a API e o app aceita.
Checklist de auditoria antes do go-live
Use isto como filtro honesto. Cada item vermelho é motivo para segurar a publicação:
| Item | O que verificar | Gravidade |
|---|---|---|
| RLS | Toda tabela com política ativa; usuário A não lê dado do B | Crítica |
| BOLA | Cada acesso a objeto confere dono/permissão no servidor | Crítica |
| Segredos | Nenhuma chave de serviço no bundle ou em variável do front | Crítica |
| Validação server-side | Regras de negócio validadas antes de gravar | Alta |
| Auth | Signup, login, reset, sessão e logout testados | Alta |
| Fluxos de dinheiro/lead | Idempotência e tratamento de falha | Alta |
| Repositório e ambientes | Código no GitHub, dev/staging/prod separados | Média |
| Testes dos caminhos críticos | Cobertura dos fluxos que geram receita ou risco | Média |
| LGPD | Coleta alinhada à política de privacidade | Média |
Se mais da metade está em vermelho, você tem um protótipo — e tudo bem. Só não venda como SaaS maduro. A mesma lógica vale para qualquer publicação apressada, como discutimos em riscos de publicar apps em produção e em vibe coding: não suba projeto de fim de semana.
O fluxo Lovable → GitHub → endurecimento
O caminho saudável não é abandonar o Lovable. É tratá-lo como insumo e aplicar engenharia por cima. Na Pixelize, o roteiro é:
- Exportar para o GitHub. Ownership começa aqui. Sem repositório sob seu controle, você depende do modelo de créditos da ferramenta e não tem onde versionar as correções. É o primeiro passo, não uma etapa futura.
- Auditoria de segurança. RLS tabela por tabela, verificação de BOLA nos acessos a objeto, varredura de segredos no bundle e no histórico do repositório. É aqui que a maior parte dos incidentes é evitada.
- Endurecimento. Escrever ou corrigir as políticas de RLS, mover validação para o servidor, tirar segredos do front, tratar erros e idempotência nos fluxos de dinheiro e lead.
- Ambientes e pipeline. Separar dev, staging e produção; configurar deploy previsível em vez de “publicar direto”. Multi-tenant, se o produto exige.
- Testes dos fluxos críticos. Cobrir o que gera receita e o que gera risco, para que a próxima alteração não reabra um buraco fechado.
- Operação com critério. Definir quem monitora, quem recebe alerta e como se responde a um incidente depois do go-live.
Esse é o mesmo rigor do caminho de MVP do zero à produção e da arquitetura segura para dados sensíveis — só que aplicado a uma base que já existe, o que costuma ser mais rápido do que começar do zero.
Quando exportar e quando chamar reforço
Se o seu app do Lovable ainda é exploração — testando ideia, sem usuário externo, sem dado real — continue iterando na ferramenta. Não há por que endurecer o que talvez você jogue fora amanhã.
O sinal de que chegou a hora de exportar e chamar reforço é simples: vai entrar usuário que você não conhece, com dado que importa. No momento em que há login de cliente, pagamento, dado pessoal ou qualquer coisa cujo vazamento gera prejuízo, a camada de engenharia deixa de ser opcional. Aí o “quase pronto” precisa virar pronto de verdade — e é esse trabalho que fazemos em desenvolvimento web, com o código que você já gerou.
O ponto que fecha o raciocínio: a ferramenta te deu velocidade na parte visível, e isso tem valor real. Ela não te deu — e nem prometeu — a parte invisível que decide se o app aguenta o mundo real sem vazar. Reconhecer essa divisão de trabalho é o que separa o founder que sobe um protótipo maduro do que descobre a falha pela reclamação de um cliente. O código gerado não é o problema; publicá-lo sem endurecer é.
Perguntas frequentes
Dá para publicar um app do Lovable direto, sem revisão?
Sobe tecnicamente, mas poucos deveriam. Sem auditoria de RLS, validação no servidor e chaves fora do front, você troca velocidade por risco de vazamento. “Quase pronto” não é “pronto para pagar cliente”.
O que é RLS no Supabase e por que importa tanto?
Row Level Security é a regra, no banco, que decide qual linha cada usuário acessa. Como o front usa uma chave pública, sem RLS correta qualquer um lê a tabela inteira. É a falha mais comum e grave em apps gerados.
O que é Broken Object-Level Authorization?
É quando o app não confere se o usuário tem direito sobre o objeto pedido. Trocar um id na URL e ver o dado de outro cliente é o exemplo. A OWASP lista como o risco número um de APIs.
Validação no cliente não basta?
Não. Tudo que roda no navegador o usuário burla. Validação de verdade é no servidor, antes de gravar. No fluxo do Lovable isso costuma faltar, e o front é justamente o lado que o atacante controla.
Meu código fica preso na plataforma?
Só se você não exportar. O caminho saudável é levar o projeto para o GitHub e operar em ambientes seus. Sem isso, não há onde aplicar o endurecimento nem como versionar correções.
Quanto trabalho é levar um app do Lovable a produção com segurança?
Depende do gap entre demo e uso real. Há correções rápidas (RLS, tirar chave do bundle) e trabalhos maiores (autorização por objeto, multi-tenant, testes). Um diagnóstico curto evita orçamento no escuro.