// Guia por ferramenta
Segurança para apps feitos em Lovable, Bolt, v0 e Replit
O gap entre protótipo e produto
Ferramentas como Lovable, Bolt, v0 e Replit fazem o MVP funcionar rápido. O problema aparece na fronteira entre "funciona na demo" e "aguenta cliente real": autorização no servidor, isolamento por cliente, validação de entrada e controle do que a IA pode fazer costumam ficar para depois — e "depois" chega com o primeiro cliente pagante.
A ferramenta não é o problema. O problema é publicar um fluxo real (login, cobrança, dados) sem revisar a fronteira que o gerador não desenhou por você.
O que revisar primeiro
Independente da ferramenta, os mesmos fluxos concentram o risco.
- Autorização no servidor, não só telas escondidas no front.
- Isolamento por cliente em toda leitura e escrita.
- Chaves e segredos fora do código do cliente/bundle.
- Validação de entrada e de upload no backend.
- Regras de acesso a banco (ex.: Supabase RLS) realmente ativas.
Armadilhas comuns por padrão
Geradores otimizam para "rodar", não para "resistir". É comum sair com política de banco permissiva, endpoint sem checagem de dono, chave exposta no front e webhook sem validação. Nenhuma dessas é culpa da ferramenta — são a parte que ninguém revisou.
Como sair do chute
Você não precisa reescrever tudo. Precisa percorrer os fluxos reais com um roteiro que force a IA a revisar acesso, dados, checkout e upload — e apontar o que corrigir agora. É para isso que serve o RET Promptbook: primeira revisão paga antes de colocar mais gente no risco.
Perguntas frequentes
App feito em Lovable/Bolt/v0/Replit é inseguro por natureza?
Não. O código gerado pode ser bom. O risco está em publicar fluxos sensíveis sem revisar a fronteira (autorização, isolamento, segredos) que o gerador não fecha automaticamente.
Preciso migrar de ferramenta para ficar seguro?
Geralmente não. A revisão olha o fluxo do produto, não a origem do código. Migrar sem revisar só muda onde o mesmo erro mora.
Uso Supabase; o RLS resolve tudo?
RLS ajuda muito, mas só se estiver ativo e correto. Muitos projetos deixam políticas permissivas ou desativadas. Confirme as regras e combine com verificação na aplicação.