RELATÓRIO DE SEGURANÇA LOVABLE — FEV 2026: 18.000 USUÁRIOS EXPOSTOS, 170+ BANCOS COMPROMETIDOS

18.697

Registros de usuários expostos em um único app

170+

Bancos completamente expostos entre 1.645 escaneados

90%

Dos apps auditados compartilham as mesmas 5 vulnerabilidades

52/100

Score médio de segurança em 200+ sites

Seu app Lovable está vulnerável?

Digite a URL do seu app Lovable em produção para checar as vulnerabilidades descritas neste relatório

O Vazamento do App Showcased: 18.000+ Usuários Expostos

O maior incidente de segurança do Lovable em fevereiro de 2026 veio de um pesquisador que testou um app EdTech em destaque da própria Lovable — um dos cases de sucesso no site da Lovable, com 100K+ visualizações e usuários reais da UC Berkeley, UC Davis e instituições da Europa, África e Ásia.

Em algumas horas, o pesquisador achou 16 vulnerabilidades de segurança, 6 delas críticas. A lógica de autenticação estava literalmente invertida — bloqueava usuários logados e deixava passar anônimos. O post foi cross-postado no r/hacking (1.200+ upvotes), r/cybersecurity (1.080+ upvotes), r/ClaudeAI (1.000+ upvotes) e r/lovable.

O que foi exposto

• 18.697 registros de usuários (nomes, e-mails, papéis) — sem precisar de autenticação
• Exclusão de conta via uma única chamada de API — sem autenticação
• Notas de alunos modificáveis por qualquer um — sem autenticação
• Capacidade de envio de e-mail em massa — sem autenticação
• Dados organizacionais enterprise de 14 instituições

O pesquisador reportou os achados para a Lovable. No início, o ticket de suporte foi fechado. Depois que os posts no Reddit ganharam tração, o time de segurança da Lovable entrou em contato, recebeu o relatório completo e começou a investigar. O desenvolvedor que construiu o app acabou reconhecendo os problemas e corrigiu as vulnerabilidades mais críticas.

Fonte: r/hacking, r/cybersecurity, r/ClaudeAI, r/lovable — fevereiro de 2026. Combinados, 3.400+ upvotes.

Carta aberta: “Você não pode vibecodar ignorando a segurança dos usuários”

Um desenvolvedor com mais de 20 anos de experiência postou uma carta aberta no r/lovable (620+ upvotes, 127 comentários) alertando a comunidade de vibe coding sobre problemas sistêmicos de segurança. O post foi cross-postado no r/vibecoding (695+ upvotes, 210 comentários) e no r/SideProject (180+ upvotes).

O desenvolvedor vinha testando apps vibe coded compartilhados no Reddit e encontrou padrões profundamente preocupantes:

• Endpoints públicos de Supabase expondo listas completas de usuários — bancos consultáveis por qualquer um com um navegador
• Auto-upgrade para premium — usuários podiam alterar is_paid, is_subscribed ou se dar 99.999 créditos
• Manipulação de dados — endpoints PUT/PATCH escancarados, permitindo deletar ou modificar dados de outros usuários
• Sem ferramenta especial — só navegador, DevTools e alguns cliques

Fonte: r/lovable, r/vibecoding, r/SideProject — 1.500+ upvotes combinados.

Investigação seguinte: “É pior do que eu pensava”

O mesmo desenvolvedor voltou depois de testar apps do próprio site launched.lovable.dev da Lovable. Os achados foram consistentes: muitos dos apps em destaque sofriam exatamente das mesmas vulnerabilidades.

Achado-chave: “Não encontrei problemas em apps Bolt, Replit ou baseados em Cursor/Cline” — as vulnerabilidades estavam concentradas em aplicações Lovable + Supabase, especificamente em políticas de RLS mal configuradas.

O desenvolvedor contatou a Lovable diretamente para perguntar quais passos estão sendo tomados para evitar que desenvolvedores lancem apps inseguros sem querer através da plataforma.

Fonte: r/lovable — 124 upvotes, 58 comentários.

170+ Bancos Expostos: a escala do problema

Um post separado no r/vibecoding (85 upvotes, 44 comentários) revelou o resultado de um scan em larga escala: em maio de 2025, pesquisadores de segurança escanearam 1.645 apps construídos com Lovable. Mais de 170 tinham bancos totalmente expostos, sem RLS ativo. Os dados expostos incluíam endereços residenciais, dados financeiros, chaves de API e registros de pagamento. Um vazamento afetou 13.000 usuários.

A confusão central: Autenticação vs Autorização

O post explicava a causa-raiz que confunde a maioria dos desenvolvedores Lovable:

• Autenticação = provar quem você é (login)
• Autorização = o que você pode acessar (RLS)

Por padrão, o Supabase expõe todas as tabelas via API. A anon_key é pública — está no seu código frontend. A ÚNICA coisa que impede acesso não autorizado é Row Level Security. Se RLS não estiver ativo, seu banco é uma API pública.

Fonte: r/vibecoding — 85 upvotes, 44 comentários.

200+ Sites Vibe Coded Escaneados: Média 52/100

Um desenvolvedor web escaneou mais de 200 sites construídos com Cursor, Bolt, Lovable, v0 e outras ferramentas de IA. O score médio de segurança foi 52 de 100. Os padrões eram sempre os mesmos:

• Chaves de API e segredos hardcoded no código-fonte
• Nenhum header de segurança (CSP, HSTS, X-Frame-Options)
• Cookies sem flags Secure ou HttpOnly
• Versões de servidor e info de debug expostas em produção
• Dependências com vulnerabilidades conhecidas que nunca recebem update

Como o desenvolvedor resumiu: “A IA faz o que você pede. Só que ela nunca pensa no que você não pediu.”

Fonte: r/VibeCodeDevs — 161 upvotes, 68 comentários.

50 Apps Auditados Manualmente: os mesmos 5 erros

Um pesquisador de segurança que auditou manualmente 50 apps construídos com Cursor, Lovable, Bolt e v0 postou seus achados no r/lovable (32 upvotes, 13 comentários). Os mesmos problemas apareceram em praticamente todo app:

1. Chaves de API hardcoded

Chaves de API da OpenAI, Stripe, Firebase direto em arquivos JavaScript visíveis no DevTools. Atacantes podem roubar chaves e acumular milhares de dólares em cobranças.

2. Políticas de RLS ausentes

Tabelas do Supabase com RLS desabilitado, deixando todos os dados de usuário consultáveis por qualquer um com a anon_key pública.

3. Validação de entrada ausente

Sem validação de requisição no servidor, permitindo manipulação direta de dados via chamadas de API.

4. Autenticação quebrada

Lógica de autenticação que “funciona” em demo, mas permite acesso não autorizado em produção. Middleware de checagem removido durante refatoração.

5. Vazamento de dados no console

Objetos completos de dados, IDs de usuário, respostas de API internas despejadas no console do navegador em cada carregamento de página.

Bônus: Bypass de premium

Usuários podiam se promover para o plano pago modificando o estado do frontend ou linhas no Supabase — sem verificação de pagamento no servidor.

Fontes: r/lovable, r/vibecoding, r/VibeCodeDevs, r/replit, r/boltnewbuilders.

Resposta da comunidade e ferramentas

A comunidade do Reddit respondeu à crise de segurança do Lovable com várias iniciativas:

• Mega-prompts de segurança: usuários do r/lovable compartilharam prompts para fazer o Lovable aplicar controles OWASP ASVS, validação de entrada, proteção contra CSRF e rate limiting durante a geração de código (85 upvotes)
• Padrões de RLS do Supabase: vários posts compartilhando templates copiáveis de políticas de RLS específicos para apps Lovable + Supabase
• Scanners de segurança: vários desenvolvedores construíram ferramentas de scan mirando especificamente apps Lovable / vibe coded, incluindo ferramentas que auto-geram prompts de correção
• Bug bounties: um desenvolvedor Lovable ofereceu $1.500 por vulnerabilidade encontrada no app em produção (r/lovable, 204 upvotes)
• Serviços de auditoria: um mercado crescente de auditores humanos oferecendo revisão de segurança especificamente para apps vibe coded

Impacto real: 47 vulnerabilidades antes de auditoria PCI

Uma startup fintech postou no r/vibeward sobre ter encontrado 47 vulnerabilidades de segurança no código gerado por IA apenas 3 semanas antes da auditoria de compliance PCI-DSS. Dessas, 12 eram bloqueadores críticos de PCI e 23 eram de severidade alta. O time usou GitHub Copilot extensivamente, e o código escrito nos 6 meses anteriores continha a maior parte dos problemas.

O padrão é claro: código gerado por IA sai rápido, mas pula o básico de segurança. O consenso da comunidade r/vibecoding (195 upvotes, 139 comentários) é que “se você está lançando produtos vibe coded com qualquer tipo de backend para o público, sem humanos de verdade auditando a segurança, você está sendo tremendamente irresponsável”.

O que desenvolvedores Lovable devem fazer agora

Com base nos achados da comunidade, este é o checklist mínimo de segurança para qualquer app Lovable antes de ir para produção:

1. 1. Habilite RLS em cada tabela. Vá para Supabase Authentication → Policies. Se ver “RLS disabled” em qualquer tabela com dados de usuário, você está exposto agora.
2. 2. Escreva políticas explícitas para SELECT, INSERT, UPDATE, DELETE. RLS habilitado sem políticas bloqueia todo mundo, inclusive o próprio app. Adicione políticas que chequem auth.uid() = user_id.
3. 3. Remova todos os segredos hardcoded do código frontend. Mova chaves de API para variáveis de ambiente e faça proxy de chamadas sensíveis via funções server-side.
4. 4. Nunca use a service_role key no código frontend. Ela ignora todo o RLS. Qualquer um consegue extrair do bundle JavaScript.
5. 5. Adicione verificação de pagamento no servidor. Não confie no estado do frontend para status premium / pago. Verifique com seu provedor de pagamento no backend.
6. 6. Remova console.log. Objetos completos de dados no console do navegador são visíveis para todo usuário.
7. 7. Rode um scan de segurança antes de cada deploy. Scan automatizado pega problemas que a revisão manual deixa passar.

Recursos relacionados

Scanner de Segurança Lovable

Rode um scan de segurança completo no seu app Lovable.

O Lovable é seguro?

Análise de segurança detalhada da plataforma Lovable.

Como proteger o Lovable

Guia passo a passo de segurança para apps Lovable.

Este relatório foi compilado a partir de discussões públicas no Reddit. Todos os dados citados vêm de posts da comunidade com suas contagens originais de upvote. O VibeEval não tem vínculo com a Lovable nem com o Supabase. Perguntas? Entre em contato com nosso time.