Passei os últimos três meses auditando apps que clientes nos trouxeram depois de construir seus MVPs no Lovable. O padrão é tão consistente que é quase entediante: chaves de serviço do Supabase expostas em bundles de cliente, zero políticas de RLS, secrets do OpenAI e Stripe hardcoded sentados ali no JavaScript para qualquer um com DevTools pegar. Toda. Vez.

Isso não é um ataque ao Lovable. A plataforma é genuinamente impressionante para prototipagem. Mas existe uma lacuna tamanho-cânion entre "demo funcionando" e "aplicação pronta para produção", e o Lovable não te avisa sobre a maioria do que está nessa lacuna. Um pesquisador da comunidade auditou 50 apps construídos com IA e encontrou os mesmos cinco erros de segurança em quase todos eles. Outro desenvolvedor verificou mais de 200 sites code-vibe e encontrou uma pontuação média de segurança de 52 em 100 -- com os piores casos concentrados especificamente em aplicações Lovable + Supabase.

Vamos caminhar por cada vulnerabilidade que continuamos encontrando, por que as próprias ferramentas do Lovable perdem elas, e exatamente como corrigir cada uma.

Tabela de Conteúdos

Vulnerabilidades de Segurança do Lovable 2026: Chaves Expostas, RLS Ausente, e O que Auditorias Detectam

A Arquitetura que Cria o Problema

Para entender por que os apps do Lovable são desproporcionalmente afetados, você precisa entender a arquitetura. O Lovable usa exclusivamente Supabase como backend. Não há opção Firebase, sem backend customizado, sem porta de fuga. Quando você constrói algo no Lovable, ele gera um frontend React que se comunica diretamente com a API REST do Supabase usando a biblioteca cliente.

O Supabase é projetado para que a chave anon seja segura para expor publicamente -- é essencialmente um identificador de projeto. O modelo de segurança depende inteiramente das políticas de Row Level Security (RLS) no nível PostgreSQL. Pense assim:

Componente Destinado a ser público? O que te protege
URL Supabase Sim Nada necessário -- é apenas uma URL
Chave anon Sim Políticas de RLS em cada tabela
Chave service_role Absolutamente não Deve ficar apenas no servidor
String de conexão do banco Não Nunca exponha para clientes

O problema é que a IA do Lovable gera código que frequentemente trata todos esses da mesma forma. Ela coloca a chave anon no frontend (está bem), mas depois cria tabelas sem habilitar RLS (catastrófico). Às vezes coloca a chave service_role no código cliente também (fim do jogo). Como um desenvolvedor no Reddit disse: "IA faz o que você pede. Só nunca pensa no que você não pediu."

Vulnerabilidade 1: Chaves do Supabase Expostas em Código Cliente

Todo app Lovable inicializa o cliente Supabase algo assim:

// src/integrations/supabase/client.ts
import { createClient } from '@supabase/supabase-js'

const supabaseUrl = 'https://xyzcompany.supabase.co'
const supabaseAnonKey = 'eyJhbGciOiJIUzI1NiIs...'

export const supabase = createClient(supabaseUrl, supabaseAnonKey)

A chave anon estar aqui está bem -- é por design. O problema vem em duas formas:

O Vazamento da Chave `service_role`

Vimos código gerado pelo Lovable onde a chave service_role acaba no código do lado do cliente, geralmente porque alguém solicitou ao IA algo como "faça isso funcionar mesmo que RLS esteja bloqueando". A solução da IA? Use a chave de admin. A chave service_role ignora todas as políticas de RLS completamente. Se estiver no seu bundle de frontend, qualquer um pode extraí-la e ter acesso completo de leitura/escrita a todo seu banco de dados.

O Arquivo `.env` Commitado no Git

Projetos Lovable implantados no GitHub frequentemente têm arquivos .env commitados no repositório. Mesmo se o repo for privado agora, se foi público alguma vez -- mesmo por um minuto -- essas chaves estão comprometidas. Bots fazem scrape do GitHub constantemente procurando exatamente esse padrão.

Como verificar:

# Procure em seu código por chaves service_role
grep -r "service_role" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.env" .

# Verifique o histórico git para secrets acidentalmente commitados
git log --all -p -- '*.env'

Como corrigir: Remova a chave service_role de todo código cliente imediatamente. Rotacione a chave no painel do Supabase (Settings → API). Use a chave apenas em código do lado do servidor -- Funções Edge do Supabase, uma rota de API Next.js, ou um backend separado.

Vulnerabilidade 2: Políticas de RLS Faltantes ou Quebradas

Essa é a grande. CVE-2025-48757 expôs 303 endpoints vulneráveis em mais de 170 apps construídos com Lovable. De acordo com Escape.tech, 83% dos bancos de dados Supabase expostos envolvem problemas de configuração de RLS.

Aqui está o que acontece por padrão quando Lovable cria uma tabela:

-- O que Lovable frequentemente gera
CREATE TABLE user_profiles (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES auth.users(id),
  full_name TEXT,
  email TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Perceba o que está faltando? RLS não está habilitado.
-- Esta tabela é totalmente legível e gravável por qualquer um com a chave anon.

Sem RLS, seu banco de dados Supabase é essencialmente uma API pública. Qualquer um que saiba sua URL de projeto e chave anon -- ambas estão no seu código de frontend -- pode fazer isso:

// Console do navegador de um atacante
const { data } = await supabase.from('user_profiles').select('*')
// Retorna dados de CADA usuário

await supabase.from('user_profiles').delete().neq('id', '')
// Deleta tudo

Três Sabores de Falha de RLS

Modo de Falha O Que Acontece Severidade
RLS não habilitado em absoluto Acesso público completo de leitura/escrita Crítica
RLS habilitado mas sem políticas definidas Ninguém consegue acessar nada (app quebra) Alta (força devs a desabilitar RLS)
Políticas muito permissivas (ex: USING (true)) Parece seguro, na verdade não é Alta

A terceira é particularmente insidiosa. Vimos Lovable gerar políticas assim quando solicitado para "corrigir as permissões":

CREATE POLICY "Allow all access" ON user_profiles
  FOR ALL
  USING (true)
  WITH CHECK (true);

Isso é teatro de RLS. Está habilitado, tem uma política, e não faz absolutamente nada.

Como uma política apropriada se parece:

-- Habilitar RLS
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;

-- Usuários podem apenas ler seu próprio perfil
CREATE POLICY "Users read own profile" ON user_profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- Usuários podem apenas atualizar seu próprio perfil
CREATE POLICY "Users update own profile" ON user_profiles
  FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

-- Apenas usuários autenticados podem inserir, e apenas para si mesmos
CREATE POLICY "Users insert own profile" ON user_profiles
  FOR INSERT
  WITH CHECK (auth.uid() = user_id);

Vulnerabilidades de Segurança do Lovable 2026: Chaves Expostas, RLS Ausente, e O que Auditorias Detectam - arquitetura

Vulnerabilidade 3: Secrets de APIs Terceirizadas Hardcoded

Essa me faz wincer toda vez. Regularmente encontramos chaves de API OpenAI (sk-...), chaves secretas de Stripe (sk_live_...), chaves SendGrid, e outras credenciais hardcoded diretamente em componentes React.

// Realmente encontrado em um arquivo gerado pelo Lovable
const openai = new OpenAI({
  apiKey: 'sk-proj-abc123...',  // Isso está no seu bundle do navegador
})

Qualquer um que abre DevTools, vai para a aba Sources, e procura por sk- ou sk_live obtém suas chaves. Atacantes automatizam isso. Existem bots que especificamente rastreiam bundles JavaScript procurando por esses padrões.

O impacto financeiro é real. Tivemos um cliente vir a nós após uma chave OpenAI exposta resultar em $4.200 em cobranças durante um fim de semana. Chaves secretas de Stripe são piores -- concedem acesso completo para processar reembolsos, visualizar dados de clientes, e modificar inscrições.

A correção: Mova todas as chamadas de API terceirizadas para funções do lado do servidor. Funções Edge do Supabase funcionam bem para isso:

// supabase/functions/openai-proxy/index.ts
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'

serve(async (req) => {
  const { prompt } = await req.json()
  
  const response = await fetch('https://api.openai.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${Deno.env.get('OPENAI_API_KEY')}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: 'gpt-4o',
      messages: [{ role: 'user', content: prompt }],
    }),
  })
  
  return new Response(JSON.stringify(await response.json()))
})

Vulnerabilidade 4: Headers de Segurança Faltantes

A verificação de mais de 200 sites encontrou que a maioria dos apps implantados no Lovable vem com zero headers de segurança. Sem Content-Security-Policy. Sem Strict-Transport-Security. Sem X-Frame-Options. Sem X-Content-Type-Options.

Isso pode parecer menor comparado a um banco de dados exposto, mas headers faltantes habilitam:

  • Clickjacking -- seu app pode ser embutido em um iframe em um site malicioso
  • Amplificação de XSS -- sem CSP, scripts injetados não têm restrições
  • Ataques de MIME type sniffing -- navegadores podem interpretar arquivos como código executável
  • Ataques de downgrade -- sem HSTS, tráfego pode ser interceptado
Header Propósito Padrão Lovable
Content-Security-Policy Previne XSS, controla carregamento de recursos Faltando
Strict-Transport-Security Força HTTPS Faltando
X-Frame-Options Previne clickjacking Faltando
X-Content-Type-Options Previne MIME sniffing Faltando
Referrer-Policy Controla informação de referrer Faltando
Permissions-Policy Controla recursos do navegador Faltando

Vulnerabilidade 5: Sem Validação ou Sanitização de Entrada

Formulários gerados pelo Lovable tipicamente enviam entrada do usuário diretamente para Supabase sem validação. Sem verificações de comprimento, sem validação de tipo, sem sanitização de HTML ou conteúdo SQL-adjacente.

Embora a camada PostgREST do Supabase previna injeção SQL tradicional, a falta de validação de entrada ainda habilita:

  • XSS armazenado através de HTML não sanitizado em campos de texto
  • Negação de serviço através de payloads extremamente grandes
  • Abuso de lógica de negócio (ex: quantidades negativas, preços de $0.00)
  • Corrupção de dados de tipos inesperados

O que a Verificação de Segurança Integrada do Lovable Realmente Verifica

O Lovable tem uma funcionalidade de "Verificação de Segurança" integrada acessível do painel. Crédito onde é devido -- existe. Mas aqui está o que ela realmente cobre versus o que não cobre:

Verificação Verificação Integrada Auditoria de Produção
Erros de sintaxe básicos ✅ ✅
CVEs conhecidos em dependências Parcial ✅
Secrets hardcoded em código-fonte ❌ ✅
RLS habilitado em todas as tabelas ❌ ✅
Correção de política de RLS ❌ ✅
Exposição de chave service_role ❌ ✅
Headers de segurança ❌ ✅
Cobertura de validação de entrada ❌ ✅
Revisão de configuração de auth ❌ ✅
Políticas de bucket de armazenamento ❌ ✅
Rate limiting ❌ ✅
Flags de segurança de cookie ❌ ✅

A verificação integrada é superficial no melhor dos casos. Não vai pegar as vulnerabilidades que realmente são exploradas.

O que uma Auditoria de Produção Detecta que a Plataforma Não Detecta

Quando fazemos uma auditoria de segurança de produção para um cliente que construiu no Lovable, aqui está o que tipicamente encontramos e corrigimos. Essa é a lista real, de engajamentos reais:

Camada de Banco de Dados

  • Tabelas com RLS desabilitado (média: 60-70% das tabelas)
  • Políticas de RLS usando true como condição
  • Políticas faltantes para operações DELETE (devs esquecem do delete)
  • Sem políticas em tabelas de junção
  • Buckets de armazenamento definidos como públicos sem restrições de upload
  • Índices faltantes em colunas usadas em condições de política de RLS (performance + segurança)

Camada de Autenticação

  • Secrets JWT fracos (os padrões do Supabase estão bem, mas às vezes as pessoas os mudam)
  • Sem requisitos de confirmação de email
  • Sem rate limiting em endpoints de auth
  • Fluxos de reset de senha sem expiração apropriada de token
  • Problemas de configuração de URL de redirecionamento OAuth

Camada de Código Cliente

  • Chaves service_role em bundles de frontend
  • Chaves de APIs terceirizadas hardcoded em componentes
  • Arquivos .env commitados no histórico git
  • Debug logging que expõe dados de usuário no console
  • Mensagens de erro que vazam informações de schema do banco

Camada de Infraestrutura

  • Nenhum header de segurança
  • Cookies sem flags Secure, HttpOnly, ou SameSite
  • Informações de versão de servidor expostas
  • Sem configuração de CORS (aceita requisições de qualquer origem)
  • Dependências com CVEs conhecidos que não foram atualizadas em meses

Um app Lovable típico que auditamos precisa de 15-25 correções antes de estar pronto para produção. A maioria delas leva menos de uma hora cada, mas você precisa saber que existem primeiro.

O Incidente do Moltbook: Um Estudo de Caso do Mundo Real

Em janeiro de 2026, pesquisadores de segurança na Wiz descobriram que Moltbook -- uma rede social de IA -- tinha seu banco de dados inteiro do Supabase exposto através de um cliente mal configurado. A chave anon estava no JavaScript do frontend (normal), mas RLS não estava configurado em tabelas críticas (catastrófico).

O resultado? 1,5 milhão de chaves de API eram acessíveis. Não apenas dados de usuário -- chaves de API reais pertencendo a usuários que tinham conectado suas contas OpenAI, Anthropic, e outras. Acesso completo de leitura e escrita a cada tabela. Um pesquisador conseguia navegar pelo banco inteiro usando apenas o cliente Supabase em um console de navegador.

A timeline de divulgação foi apertada -- o mantenedor do Moltbook corrigiu as tabelas críticas dentro de horas de ser contatado. Mas a janela de dano era desconhecida. Por quanto tempo o banco de dados esteve exposto antes de alguém verificar? Ninguém sabe.

Esse é o padrão Lovable + Supabase acontecendo em escala. A plataforma gera código funcionando. Ela apenas não gera código seguro.

Como Corrigir um App Lovable Antes de Ir para Produção

Aqui está a checklist que usamos. Você pode fazer a maioria disso você mesmo se estiver confortável com SQL e o painel do Supabase:

Passo 1: Auditar Cada Tabela para RLS

-- Execute isso no Editor SQL do Supabase para encontrar tabelas sem RLS
SELECT schemaname, tablename, rowsecurity 
FROM pg_tables 
WHERE schemaname = 'public';

Qualquer tabela onde rowsecurity é false precisa de atenção imediata.

Passo 2: Procure no Seu Código por Secrets

# Procure por padrões de secrets comuns
grep -rn 'sk-' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'sk_live' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'service_role' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'SUPABASE_SERVICE' --include='*.ts' --include='*.tsx' --include='*.env' .

Passo 3: Escrever Políticas de RLS Apropriadas

Para cada tabela, escreva políticas explícitas para SELECT, INSERT, UPDATE, e DELETE. Sempre use verificações auth.uid():

-- Template para uma tabela de propriedade do usuário
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

CREATE POLICY "select_own" ON your_table FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "insert_own" ON your_table FOR INSERT
  WITH CHECK (auth.uid() = user_id);

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

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

Passo 4: Mover Chamadas de API para o Lado do Servidor

Qualquer chamada de API terceirizada que necessite uma chave secreta precisa rodar em uma Função Edge do Supabase ou um backend separado. Isso é inegociável.

Passo 5: Adicionar Headers de Segurança

Se você está implantando para Netlify, Vercel, ou Cloudflare, adicione headers via sua configuração. Para Netlify, crie um arquivo _headers. Para um app Next.js, adicione eles em next.config.js.

Passo 6: Considere uma Migração de Framework

Para qualquer coisa além de um MVP, frequentemente recomendamos migrar código React gerado pelo Lovable em um projeto Next.js ou Astro apropriado. Isso te dá rotas de API do lado do servidor, manuseio apropriado de variáveis de ambiente, middleware para verificações de auth, e um pipeline de build real. É mais trabalho inicial, mas a postura de segurança é noite e dia.

Ferramentas para Verificação Automatizada

Várias ferramentas emergiram especificamente para auditar apps gerados com IA:

Ferramenta O Que Verifica Custo
Ship Safe (npx ship-safe audit .) RLS, exposição de service_role, buckets de armazenamento, CVEs de dependência Grátis, open-source
Vibe App Scanner (vibeappscanner.com) Verificação de segurança completa para apps construídos com IA Verificação iniciante grátis
Snyk Vulnerabilidades de dependência, code scanning Tier gratuita disponível
Painel Supabase → Auth → Policies Editor visual de políticas de RLS Incluído com Supabase

Ship Safe é a que eu começaria. Ele roda localmente, nada deixa sua máquina, e é especificamente construído para as problemas de configuração do Supabase que ferramentas de IA criam:

npx ship-safe audit .

Ele vai sinalizar RLS desabilitado, chaves service_role em código cliente, buckets de armazenamento abertos, configuração de auth fraca, secrets hardcoded, e CVEs de dependência.

Perguntas Frequentes

A chave anon do Supabase é segura para expor em código de frontend? Sim -- mas apenas se você tiver políticas de RLS apropriadas em cada tabela. A chave anon é projetada para ser pública. É como um identificador de projeto. A segurança vem das políticas de RLS que controlam o que essa chave pode realmente acessar. Sem RLS, a chave anon dá a qualquer um acesso completo do banco de dados.

Lovable habilita RLS por padrão ao criar tabelas? Não. A partir de início de 2026, Lovable cria tabelas do Supabase sem habilitar RLS por padrão. Essa é a lacuna de segurança mais grande na plataforma. Você precisa manualmente habilitar RLS e escrever políticas para cada tabela depois que Lovable as gera. CVE-2025-48757 foi um resultado direto desse comportamento padrão.

Como faço para verificar se meu app Lovable tem secrets expostos? Abra seu app implantado em um navegador, abra DevTools (F12), vá para a aba Sources, e procure em todos os arquivos por sk-, sk_live, service_role, e qualquer prefixo de chave de API para serviços que você usa. Também execute npx ship-safe audit . localmente em seu código para detecção automatizada.

A verificação de segurança integrada do Lovable consegue pegar problemas de RLS? A verificação de segurança integrada não verifica problemas de configuração de RLS, políticas faltantes, ou chaves service_role expostas. Ela cobre problemas em nível de código básicos mas perde as vulnerabilidades de banco de dados e infraestrutura que representam o risco mais alto. Você precisa de ferramentas externas para uma avaliação de segurança real.

O que aconteceu com CVE-2025-48757? CVE-2025-48757 foi uma divulgação de vulnerabilidade que identificou 303 endpoints vulneráveis em mais de 170 apps construídos com Lovable. A causa raiz foi Lovable criar tabelas do Supabase sem habilitar RLS, deixando bancos de dados inteiros acessíveis para qualquer um com a chave anon publicamente disponível. Ela destacou a natureza sistêmica do problema.

Devo migrar para longe do Lovable para apps de produção? Não necessariamente. Lovable é excelente para prototipagem rápida e construir MVPs. Mas o código gerado precisa de endurecimento de segurança significativo antes de usar em produção. Muitos times usam Lovable para construir a versão inicial, depois migram para um framework apropriado com renderização do lado do servidor, manuseio apropriado de secrets, e middleware de segurança. Essa é uma abordagem razoável.

Quanto tempo leva para assegurar um app Lovable para produção? Para um app típico com 10-20 tabelas, espere 2-5 dias de trabalho focado para auditar todas as políticas de RLS, mover secrets para o lado do servidor, adicionar headers de segurança, validar entradas, e testar tudo. Apps mais complexos com buckets de armazenamento, inscrições em tempo real, e múltiplos papéis de usuário podem levar mais tempo. Não é impossível, mas não é uma tarefa de uma hora também.

Outros construtores de apps IA como Bolt ou Cursor são mais seguros que Lovable? A verificação de mais de 200 sites encontrou que vulnerabilidades de segurança estavam concentradas em aplicações Lovable + Supabase especificamente. Apps Bolt, Replit, e baseados em Cursor/Cline não mostraram o mesmo padrão de problemas de configuração de RLS. Isso não significa que eles são perfeitamente seguros -- todo código gerado por IA precisa de revisão -- mas a integração Supabase específica do Lovable cria uma classe única de vulnerabilidades de exposição de banco de dados que outras ferramentas não têm.