Um pesquisador alemão escaneou 159 mil projetos criados no Lovable. O que encontrou deveria tirar o sono de qualquer dev que já publicou um app “vibe-coded” em produção: bancos de dados inteiros abertos para o mundo, sem precisar nem de login.

Passaportes. Números reais. Datas de validade. Nacionalidades. Mais de mil registros com documentos de identidade, acessíveis por qualquer pessoa com um navegador e cinco minutos de curiosidade. E isso é só o começo.

O que a Crissy Field encontrou

A firma de segurança alemã Crissy Field publicou uma pesquisa que analisou 159.041 projetos criados no Lovable entre dezembro de 2025 e setembro de 2026. Desses, 34.545 usavam Supabase como banco de dados. O resultado foi brutal:

• 24.664 sites expunham registros do banco sem exigir autenticação
• 7.403 sites (30% dos analisados) tinham endereços de email acessíveis publicamente
• 10.560 tabelas continham dados pessoais legíveis por qualquer um

Um fórum de lifestyle alemão sozinho expôs mais de 80 mil perfis com nomes completos, emails, datas de nascimento e gênero, além de 200 mil mensagens de chat privadas. Organizadores de eventos e restaurantes vazaram dezenas de milhares de registros com emails, telefones, endereços postais e informações de pagamento.

E aí vem o dado mais assustador: um provedor de serviços expôs mais de mil registros contendo números de passaporte, datas de validade e nacionalidades. Documentos de identidade reais, de pessoas reais, jogados na internet sem proteção nenhuma.

O problema não é o Lovable. É o Supabase mal configurado.

Antes de sair cancelando sua conta no Lovable, entenda o que realmente aconteceu. O Lovable não foi hackeado. Ninguém explorou uma vulnerabilidade zero-day na plataforma. O problema é muito mais simples e, por isso, muito mais perigoso: Row Level Security (RLS) desabilitado.

O Supabase funciona assim: quando você cria uma tabela pelo SQL Editor, o RLS vem desabilitado por padrão. Isso significa que qualquer pessoa com a anon key (que fica exposta no JavaScript do frontend, e isso é por design) consegue ler, editar e deletar qualquer registro de qualquer usuário.

A anon key do Supabase não é uma senha. Ela é uma chave pública, feita para ficar no frontend. A segurança não vem da chave, vem das políticas de RLS que você configura em cada tabela. Sem RLS, a anon key vira um passe livre para o banco inteiro.

-- Isso é tudo que você precisa para proteger uma tabela
ALTER TABLE users ENABLE ROW LEVEL SECURITY;

CREATE POLICY "users_select_own" ON users
  FOR SELECT USING (auth.uid() = id);

CREATE POLICY "users_update_own" ON users
  FOR UPDATE USING (auth.uid() = id);

Quatro linhas de SQL. É isso que separa “meu app está seguro” de “passaportes de mil pessoas estão na internet”.

89% dos apps Lovable não têm RLS

Um pesquisador independente escaneou 50 apps implantados pelo Lovable e os números são absurdos:

• 89% não tinham RLS habilitado em nenhuma tabela
• 34% expunham a chave service_role no código do cliente
• 28% faziam queries diretas na tabela auth.users
• 22% guardavam secrets em variáveis de ambiente públicas
• 18% não tinham nenhuma validação de input

A chave service_role é o pior caso possível. Enquanto a anon key pelo menos respeita as políticas de RLS (quando existem), a service_role bypassa tudo. É a chave de modo deus do Supabase. Qualquer pessoa que abra o DevTools do navegador, vá na aba Network ou Sources, e procure por essa string, ganha acesso irrestrito ao banco de dados inteiro.

// NUNCA faça isso no frontend
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'https://xyz.supabase.co',
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...' // service_role key = DESASTRE
)

Eu já vi isso acontecer em projeto real. O dev encontra um erro de RLS durante o desenvolvimento, pede pro Lovable “consertar” via chat, e a IA sugere usar a service_role key porque funciona imediatamente. A query passa, o dev fica feliz, e o banco fica completamente exposto.

Como o ataque funciona na prática

Não precisa ser hacker. Não precisa de ferramenta especial. O fluxo é embaraçosamente simples:

1. Encontre a anon key e a URL do Supabase

Abra qualquer app Lovable no navegador, aperte F12, vá em Sources ou Network e procure por supabase. A URL e a chave estarão lá, em texto puro, no bundle JavaScript.

2. Use a API REST do Supabase diretamente

# Listar todos os registros de qualquer tabela
curl "https://xyz.supabase.co/rest/v1/users?select=*" \
  -H "apikey: ANON_KEY_AQUI" \
  -H "Authorization: Bearer ANON_KEY_AQUI"

3. Se a tabela não tem RLS, tudo volta

Nomes, emails, senhas (sim, alguns apps guardam senhas em texto puro), dados de pagamento, documentos. Tudo. Sem filtro, sem limite.

4. Se encontrou a service_role, acabou

Com a service_role, você pode até deletar tabelas inteiras, criar novos usuários admin, ou exfiltrar o banco completo. O Supabase não vai bloquear nada porque essa chave foi feita para operações server-side sem restrições.

O elefante na sala: vibe coding gera código inseguro

Essa pesquisa não é sobre o Lovable especificamente. É sobre um problema estrutural do vibe coding: plataformas de geração de código por IA não entendem segurança no mesmo nível que um dev sênior.

O Lovable gera apps funcionais rapidamente. O Supabase fornece um backend poderoso com autenticação embutida. Mas nenhum dos dois te avisa com um popup vermelho piscante dizendo “ATENÇÃO: SEU BANCO ESTÁ ABERTO PARA O MUNDO INTEIRO”.

Não é só o Lovable. O Bolt.new tem o mesmo problema. O Cursor, quando gera código Supabase, frequentemente ignora RLS. Qualquer ferramenta de IA que gere integrações com banco de dados corre esse risco porque o código funciona perfeitamente sem segurança. Os testes passam. A demo roda. O cliente fica impressionado. E os dados ficam expostos.

Uma pesquisa separada do site SecurityScanner.dev encontrou cinco categorias de falhas recorrentes em apps Lovable:

1. RLS desabilitado (~18% dos apps auditados): tabelas como client_emails com uma coluna literal chamada password
2. Storage buckets públicos: um app tinha 8 buckets listáveis publicamente com avatares, recibos e anexos
3. Confusão entre tipos de chave: devs tratando a anon key como secreta enquanto a service_role fica no frontend
4. Headers de segurança ausentes: 100% dos apps analisados não tinham HSTS, CSP, X-Frame-Options
5. Rotas de admin expostas: painéis administrativos enviados ao browser sem verificação server-side de permissões

O que o Lovable deveria fazer (e o que você pode fazer agora)

O Lovable poderia resolver boa parte disso com três mudanças:

1. Habilitar RLS por padrão em toda tabela criada pelo gerador de código
2. Nunca sugerir a service_role key em nenhum contexto de frontend
3. Rodar um scan automático de segurança antes de cada deploy, verificando tabelas sem RLS

Mas você não precisa esperar o Lovable agir. Se você tem um app em produção construído com Lovable (ou qualquer plataforma de vibe coding + Supabase), faça isso agora:

Checklist de emergência

-- 1. Habilite RLS em TODAS as tabelas
DO $$
DECLARE
  tbl RECORD;
BEGIN
  FOR tbl IN
    SELECT tablename FROM pg_tables
    WHERE schemaname = 'public'
  LOOP
    EXECUTE format('ALTER TABLE public.%I ENABLE ROW LEVEL SECURITY;', tbl.tablename);
  END LOOP;
END $$;

-- 2. Crie políticas básicas de leitura por owner
CREATE POLICY "select_own" ON sua_tabela
  FOR SELECT USING (auth.uid() = user_id);

-- 3. Crie políticas de escrita
CREATE POLICY "insert_own" ON sua_tabela
  FOR INSERT WITH CHECK (auth.uid() = user_id);

CREATE POLICY "update_own" ON sua_tabela
  FOR UPDATE USING (auth.uid() = user_id);

CREATE POLICY "delete_own" ON sua_tabela
  FOR DELETE USING (auth.uid() = user_id);

Verifique suas chaves

# Procure pela service_role no seu código frontend
grep -r "service_role\|eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" \
  --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx" \
  src/

Se encontrar a service_role em qualquer arquivo do frontend:

1. Vá no dashboard do Supabase
2. Gere uma nova service_role key (a antiga fica inválida)
3. Remova toda referência da chave antiga do código e do histórico de chat do Lovable
4. Use apenas a anon key no frontend
5. Mova operações que precisam da service_role para Edge Functions ou um backend server-side

Storage buckets

-- Verifique quais buckets estão públicos
SELECT id, name, public FROM storage.buckets;

-- Torne privado se necessário
UPDATE storage.buckets SET public = false WHERE name = 'seu_bucket';

Vibe coding não é desculpa para ignorar segurança

A frase mais repetida nos comentários do Hacker News sobre essa pesquisa foi: “uma plataforma fácil de usar não elimina a necessidade de revisão por especialista”. E é exatamente isso.

Vibe coding é incrível para prototipar. Para validar ideias. Para construir MVPs rápido. Mas no momento em que você coloca dados reais de pessoas reais no sistema, as regras mudam. Você não está mais brincando de programar. Você tem responsabilidade legal sobre dados pessoais, especialmente na Europa com a GDPR e no Brasil com a LGPD.

O pesquisador da Crissy Field resumiu bem: “verificações automatizadas não substituem uma avaliação profissional de segurança”. Isso não significa que todo app precisa de um pentest de R$ 50 mil. Significa que antes de ir para produção, alguém que entende de segurança precisa olhar pelo menos:

• Políticas de RLS em cada tabela
• Quais chaves estão no frontend
• Se storage buckets estão fechados
• Se rotas de admin têm verificação server-side
• Se dados sensíveis estão criptografados em repouso

Cada um desses checks leva menos de 30 minutos. É menos tempo do que você gastou escolhendo a paleta de cores do app.

Lições de quem já passou por isso

Eu conversei com devs que tiveram apps Lovable comprometidos depois dessa pesquisa ser publicada. O padrão é sempre o mesmo: o app foi construído em uma tarde, ficou bonito, o cliente aprovou, e ninguém nunca abriu o dashboard do Supabase para verificar as políticas de segurança.

Um deles me contou que descobriu o problema quando um usuário do app mandou email dizendo que conseguia ver os dados de outros clientes. Não foi um hacker. Foi um usuário comum que clicou no lugar errado e viu informações que não deveria. O dev teve que mandar email para 2.000 usuários avisando sobre o vazamento. Na Europa, isso implica notificação obrigatória à autoridade de proteção de dados em até 72 horas.

Outro caso que circulou nos fóruns: um freelancer entregou um app de agendamento médico feito no Lovable. Prontuários de pacientes ficaram acessíveis publicamente por três semanas até alguém notar. Na área de saúde, dados médicos têm proteção legal ainda mais rigorosa que dados pessoais comuns.

O ponto não é culpar o dev individual. É reconhecer que o fluxo de trabalho do vibe coding tem um buraco enorme: não existe momento de revisão de segurança no pipeline. Você vai do prompt para o deploy sem nenhum checkpoint te perguntando “ei, você verificou se seu banco está aberto?”.

Compare com o deploy tradicional. No CI/CD de qualquer empresa séria, existem etapas de SAST (análise estática), DAST (análise dinâmica), review de código, e aprovação antes de ir para produção. No vibe coding, o pipeline é: prompt, preview, deploy. Três cliques e você está em produção com dados reais.

O futuro do vibe coding precisa de guardrails

Essa pesquisa vai ser um divisor de águas. Não porque o Lovable vai morrer (não vai), mas porque a indústria precisa entender que ferramentas de IA que geram código para produção precisam de guardrails de segurança embutidos.

Imagina se o Supabase habilitasse RLS automaticamente em toda tabela nova e exigisse que o dev criasse policies explicitamente para permitir acesso. A maioria desses 24 mil sites vulneráveis simplesmente não existiria.

Imagina se o Lovable rodasse um supabase inspect db policies automaticamente antes de cada deploy e bloqueasse o publish quando encontrasse tabelas sem RLS. O dev seria “forçado” a pensar em segurança, mesmo que por cinco minutos.

Essas mudanças estão vindo. O Supabase já tem um Security Advisor que alerta sobre tabelas sem RLS. O Lovable provavelmente vai integrar algo similar depois desse escândalo. Mas até lá, a responsabilidade é sua.

Se você publicou um app com Lovable, Bolt, ou qualquer outra plataforma de vibe coding usando Supabase: pare o que está fazendo e verifique seu RLS agora. Não amanhã. Agora. Porque enquanto você lê esse parágrafo, alguém pode estar fazendo um curl nas suas tabelas.

Fonte de inspiração: Lovable apps expose passport details and more than 200K private messages (Crissy Field)