O LOVABLE É SEGURO? UMA ANÁLISE DE SEGURANÇA

O Lovable é seguro? A resposta curta

O Lovable como plataforma é seguro. Apps construídos com Lovable não são seguros por padrão. A plataforma roda em Supabase, força HTTPS e aplica patches na própria infraestrutura. Os apps gerados sobem com um conjunto previsível de falhas que o desenvolvedor normalmente não auditou — Row Level Security ausente, chaves de API expostas e checagens de dono faltando em rotas CRUD. Tudo corrigível, mas você precisa escanear antes.

Os modos de falha são consistentes em todos os apps Lovable que analisamos, o que na verdade é boa notícia: você confere a lista inteira numa única passada.

As três falhas que mais importam

1. Row Level Security ausente no Supabase

Todo app Lovable usa Supabase, e o Supabase expõe uma API REST pública para cada tabela. Sem Row Level Security (RLS) ativo e com políticas corretas, essa API dá acesso total de leitura e escrita ao banco para qualquer um que saiba a URL do Supabase — que sobe dentro do JavaScript do seu app.

O que está em risco: e-mails de usuários, hashes de senha, dados pessoais, registros de pagamento, mensagens privadas, anotações internas. Qualquer coisa armazenada numa tabela desprotegida pode ser lida ou modificada de forma anônima.

Por que isso continua acontecendo: a IA do Lovable cria tabelas novas conforme as features vão sendo adicionadas, mas não acrescenta políticas de RLS de forma consistente em cada tabela. Um app que começa seguro pode ficar vulnerável depois de uma única feature nova.

Como corrigir: habilite RLS em cada tabela no dashboard do Supabase e escreva políticas que batam com a sua lógica de autenticação. Veja o Supabase RLS Checker para validar cada tabela.

-- Política mínima: o usuário só lê linhas próprias
alter table projects enable row level security;

create policy "owner_can_read"
  on projects for select
  using (auth.uid() = owner_id);

create policy "owner_can_write"
  on projects for insert with check (auth.uid() = owner_id);

create policy "owner_can_update"
  on projects for update using (auth.uid() = owner_id);

create policy "owner_can_delete"
  on projects for delete using (auth.uid() = owner_id);

Erro frequente: escrever só uma cláusula using para select e esquecer o caminho insert/update/delete. Sem with check, um usuário consegue inserir uma linha com owner_id alheio e atribuí-la a outra pessoa.

2. Chaves de API expostas no bundle do frontend

Apps Lovable frequentemente embutem chaves de API de serviços de terceiros (Stripe, OpenAI, SendGrid, ferramentas de analytics) diretamente no bundle JavaScript. Qualquer pessoa que abra o DevTools consegue ler. Bots de coleta automática de credenciais acham em questão de horas depois do deploy.

Como corrigir: mova todas as chaves que não foram feitas para uso no client — qualquer coisa além da anon key do Supabase, publishable key do Stripe, Google Maps key com restrições de referrer e similares — para trás de um proxy backend ou de uma Edge Function do Supabase. Use o Token Leak Checker para encontrar chaves expostas.

Autoteste rápido: abra o app deployado, aperte F12, vá no tab Sources e procure no JS bundleado por sk_live_, sk_test_, xoxb-, eyJ, AKIA. Cada match é no mínimo um evento de re-key, muitas vezes pior.

// Antipadrão: chave da OpenAI no frontend
const openai = new OpenAI({
  apiKey: import.meta.env.VITE_OPENAI_KEY, // entra no bundle, legível
})

// Correto: Edge Function como proxy
const res = await fetch('/api/ask', { method: 'POST', body: prompt })

A Edge Function guarda a chave como segredo, adiciona uma checagem de auth contra a sessão do Supabase e ainda pode aplicar rate limiting por usuário — três camadas de proteção que a chamada direta do browser não tem.

3. BOLA / IDOR em rotas CRUD geradas

Endpoints de recurso gerados por IA tipicamente filtram pelo ID, mas pulam a verificação de “esse usuário é dono desse ID?”. Isso significa que trocar o ID de um projeto na URL pode expor o projeto de outro usuário, dados bancários ou informações privadas. Esse é o padrão Broken Object-Level Authorization, e é a classe de bug mais danosa em apps Lovable em produção.

Como corrigir: cada endpoint que recebe um ID de recurso precisa verificar que o usuário autenticado é dono do recurso antes de retornar dados. No Supabase, isso geralmente aparece como uma política de RLS que checa auth.uid() = owner_id.

Receita de teste para encontrar BOLA num app Lovable:

1. Faça login com o Usuário A, crie um recurso, copie o ID da URL.
2. Saia, faça login com o Usuário B.
3. Reconstrua a URL com o ID do Usuário A. Se o app responder com os dados — em vez de 403/404 — BOLA confirmado.
4. Repita para endpoints PUT/DELETE. O caso mais perigoso é um endpoint de escrita que altera recursos alheios.

Problemas de segurança comuns em apps Lovable

Chaves de API expostas

Ferramentas de IA embutem chaves direto nos bundles de JavaScript. Elas ficam visíveis para qualquer um que inspecione o código-fonte e para bots em minutos após o deploy.

Políticas de RLS ausentes

Aplicações em Supabase são lançadas sem Row Level Security, permitindo leitura e escrita não autorizadas nos dados de usuários.

Checagem de dono ausente (BOLA)

Endpoints CRUD gerados filtram pelo ID, mas pulam a checagem de autorização que garante que o usuário é dono do recurso.

Validação de entrada insuficiente

Código gerado por IA frequentemente presume que a entrada é válida, abrindo a porta para SQL injection, XSS e ataques de prompt injection.

Cabeçalhos de segurança ausentes

Content-Security-Policy, Strict-Transport-Security, X-Frame-Options e Referrer-Policy geralmente não estão presentes em deploys gerados por IA.

Buckets de Storage públicos

Supabase Storage e buckets de terceiros frequentemente sobem com leitura anônima liberada, vazando uploads para o mundo todo.

Service-role key no lugar da anon key

Algumas gerações do Lovable acabam colocando a service_role key do Supabase no frontend porque alguma feature não funcionava com a anon key por causa do RLS. A service_role key ignora o RLS por completo. É o pior cenário: cada tabela, cada linha, legível e modificável sem autenticação.

Rate limits ausentes nos endpoints de auth

As rotas de login e signup de um app Lovable não têm proteção contra brute-force por padrão. Isso abre a porta para credential stuffing e enumeração de contas. Configure os rate limits do Supabase nos Auth Settings e adicione CAPTCHA para os endpoints públicos.

Erros comuns no fluxo com Lovable

• Garantir a primeira tabela direitinho, esquecer das próximas. A próxima feature cria uma tabela nova que sobe sem política. A auditoria precisa se repetir a cada release, não só no primeiro launch.
• Deixar o bucket de Storage em “Public” porque senão o upload de imagem não funciona. A resposta certa é uma signed URL por request, não um bucket aberto.
• Tomar a URL de preview do Lovable como “produção”. O preview muitas vezes está acessível sem camada de auth. Antes do launch real, a custom domain com a Site URL correta precisa estar configurada no Supabase Auth.
• Usar o tab do editor de código no Lovable para “testar rápido” um segredo. Os valores entram no build e no repo conectado. Use os Edge Function Secrets do Supabase ou as env vars de Vercel/Netlify.

Checklist pré-launch para apps Lovable

1. RLS ativo em cada tabela — verifique no dashboard do Supabase, em Authentication → Policies, que cada tabela tem pelo menos uma política.
2. Bundle do frontend escaneado por segredos — npm run build, depois grep -r 'sk_\|sk-proj\|service_role' dist/.
3. Teste de BOLA com duas contas de teste — como descrito acima, percorra cada rota baseada em ID.
4. Buckets de Storage em Private — tudo que não deva ser explicitamente público.
5. Rate limits de auth configurados — Supabase → Authentication → Rate Limits.
6. Custom domain com Site URL correta registrada no Supabase Auth, para que magic links não apontem para o preview do Lovable.
7. Branch protection em main no repositório do GitHub conectado, para que cada commit passe por um PR com scan automatizado.

Avaliação de segurança

O que o Lovable faz bem

• Integração com Supabase traz Postgres gerenciado com defaults sólidos
• Autenticação embutida com provedores OAuth
• HTTPS automático em todo deploy
• Patches regulares de segurança da plataforma
• Modos de falha previsíveis tornam o scan barato

O que você precisa verificar por conta própria

• Row Level Security em cada tabela (a maior alavanca)
• Higiene de credenciais no bundle do frontend
• Autorização em cada endpoint que aceita um ID de recurso
• Validação de entrada em cada formulário e chamada de API
• Cabeçalhos de segurança no app em produção
• Políticas de Storage e signed URLs no lugar de leitura pública
• Rate limits em endpoints de auth e API
• Zero service_role key no bundle do browser

Lovable para empresas

O Lovable é pensado principalmente para builders solo e times pequenos. Se você quer usar em contexto corporativo:

• Projeto próprio do Supabase em vez da integração default do Lovable, para que seu time de segurança mantenha controle total sobre Auth Settings, backups e audit logs.
• Edge Functions self-hosted para cada API de terceiros com segredos de servidor, em vez de chaves no frontend.
• Gate de CI no repositório do GitHub conectado que rode um scan de segurança antes de cada deploy.
• DPA/contrato com Lovable e Supabase antes de processar dados pessoais reais.
• Estratégia de backup ativa no Supabase — o Lovable não cuida disso para você.

O veredito

O Lovable é seguro como plataforma de desenvolvimento. Apps construídos com Lovable precisam de uma revisão de segurança antes do deploy para produção. As três checagens que importam — RLS, credenciais, autorização — são mecânicas e escanáveis. Rode antes de cada lançamento, todo lançamento. Um lançamento viral com RLS ausente é um vazamento viral.

Recursos relacionados

• Scanner de Segurança Lovable — rode um scan completo no seu app Lovable
• Checklist de Segurança Lovable — checklist passo a passo pré-lançamento
• Guia de Segurança Lovable — aprofundamento nos problemas comuns
• Riscos de Segurança em Vibe Coding — o padrão geral de falhas em ferramentas de IA
• Token Leak Checker — scan focado em chaves de API expostas
• Supabase RLS Checker — verifica se cada tabela do Supabase tem uma política correta
• Vibe Code Scanner — scan mais amplo em todas as plataformas de apps gerados por IA

Analise seu app Lovable

Rode o scanner gratuito do VibeEval na URL do seu app Lovable em produção. Resultados em menos de 60 segundos.