Por que todo projeto Lovable precisa de teste de segurança

O risco escondido no desenvolvimento com IA

O Lovable permite construir aplicações inteiras em pouco tempo, mas nessa velocidade a segurança costuma ficar para trás. Ferramentas de segurança tradicionais não foram feitas para código gerado por IA e deixam passar os padrões que surgem quando uma IA escreve boa parte da aplicação. Por isso existe o Scanner de Segurança Lovable.

O que torna projetos Lovable diferentes?

Assistentes de código com IA como o Lovable introduzem riscos que scanners tradicionais não capturam:

• Vulnerabilidades por padrão: a IA às vezes gera padrões de código que funcionam perfeitamente mas contêm falhas sutis de segurança
• Pontos cegos em integrações: quando a IA conecta serviços e APIs diferentes, brechas de segurança podem surgir entre componentes
• Riscos de iteração rápida: a velocidade do desenvolvimento com IA pode fazer a dívida de segurança crescer mais rápido do que uma revisão manual consegue pegar

Problemas reais que encontramos em projetos Lovable

Padrões comuns em apps Lovable:

Os 6 fluxos de vibe coding que mais quebram

“Vibe coding” (entregar um app funcionando conversando com uma IA, sem ler metade do código gerado) tende a quebrar nos mesmos seis fluxos:

Em todos eles a UI parece correta e o app funciona, mas o endpoint por trás tem um achado crítico. O scanner percorre os seis automaticamente. Para entender por que esses padrões aparecem em código gerado por IA, veja Vibe Coding Security Checks e o baseline RLS do caso da beauty blogger.

Más configurações de RLS: a vulnerabilidade #1

Nos 1.430+ apps Lovable escaneados, a vulnerabilidade mais frequente são políticas de Row Level Security (RLS) ausentes ou mal configuradas.

O Lovable usa Supabase como banco de dados. O Supabase expõe um endpoint público de API que qualquer um pode chamar diretamente. Sem políticas de RLS, nada impede um atacante de ler cada linha do seu banco, modificar dados de outros usuários ou deletar registros completamente.

As quatro checagens de RLS que toda tabela precisa

RLS exige uma política por operação, por tabela. Nosso scanner roda as quatro checagens em cada tabela pública que descobre:

Erro comum: testar só SELECT, ver que está trancado e subir, deixando as escritas abertas.

Políticas quebradas que parecem corretas

Estas políticas de RLS compilam e o app funciona, mas a tabela continua exposta:

-- RUIM: sem WITH CHECK o usuário pode INSERT linhas de qualquer um
CREATE POLICY "insert own" ON posts
  FOR INSERT USING (auth.uid() = user_id);

-- RUIM: UPDATE só com USING; usuário atualiza a própria linha
-- e muda o user_id para o de outra pessoa ao mesmo tempo
CREATE POLICY "update own" ON posts
  FOR UPDATE USING (auth.uid() = user_id);

-- RUIM: lê as próprias + marcadas como públicas, sem filtro
-- de coluna: campos sensíveis em linhas "públicas" vazam
CREATE POLICY "read public or own" ON posts
  FOR SELECT USING (is_public OR auth.uid() = user_id);

-- RUIM: a clássica correção "só pra funcionar"
CREATE POLICY "allow all" ON posts FOR ALL USING (true);

As versões corrigidas:

-- BOM: INSERT com WITH CHECK prende a nova linha ao chamador
CREATE POLICY "insert own" ON posts
  FOR INSERT WITH CHECK (auth.uid() = user_id);

-- BOM: UPDATE exige que a linha atual pertença ao chamador
-- E que a nova versão também (impede transferência de dono)
CREATE POLICY "update own" ON posts
  FOR UPDATE USING (auth.uid() = user_id)
              WITH CHECK (auth.uid() = user_id);

-- BOM: DELETE com escopo de dono
CREATE POLICY "delete own" ON posts
  FOR DELETE USING (auth.uid() = user_id);

-- BOM: SELECT explícito, sem ambiguidade
CREATE POLICY "read own" ON posts
  FOR SELECT USING (auth.uid() = user_id);

Para colunas com PII (e-mail, telefone, stripe_customer_id), prefira uma view com colunas restritas em vez de grants em nível de coluna, que é mais fácil de auditar.

Teste seu RLS

Para uma primeira passada, abra seu app Lovable em produção, pegue a URL do Supabase e a anon key na aba Network e rode:

# Substitua pelo seu projeto + anon key + tabela
SUPA="https://<project>.supabase.co"
KEY="<anon_key>"
TABLE="profiles"

# Probe de leitura: deve vir vazio ou 401 deslogado
curl "$SUPA/rest/v1/$TABLE?select=*&limit=5" \
  -H "apikey: $KEY" -H "Authorization: Bearer $KEY"

# Probe de escrita: deve ser 401 ou rejeição por política
curl -X POST "$SUPA/rest/v1/$TABLE" \
  -H "apikey: $KEY" -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"id":"rls-probe-delete-me"}'

Se vierem linhas ou a escrita passar, você tem um crítico. Rode o Supabase RLS Checker gratuito para o relatório completo por tabela, ou cole a URL no scanner no topo desta página para a auditoria Lovable completa (auth, storage, edge functions e chaves, além de RLS).

Quando RLS não basta

RLS barra a anon key. Não barra:

• Edge Functions usando a service-role key: ignoram o RLS por completo. Qualquer erro lógico na função dá leitura e escrita completas no banco.
• JWTs vazados: se o JWT de um usuário logado vaza (XSS, um gist público, uma captura de tela), o RLS entrega ao atacante o que aquele usuário veria.
• Storage: tem regras parecidas com RLS por bucket e por objeto, configuradas separadamente. Em apps Lovable, o bucket costuma ficar público.
• Views e funções de banco: uma função SECURITY DEFINER roda com privilégios do criador, não do chamador. Se recebe um ID fornecido pelo usuário e confia, o RLS vira irrelevante.

Nosso scanner testa as quatro. Para entender o modelo de política subjacente, veja o guia de RLS do Supabase e o checklist de segurança do Supabase.

Como o Scanner de Segurança Lovable funciona

Ao escanear seu projeto:

1. Descoberta automática: rastreamos sua aplicação para entender estrutura, rotas e funcionalidade
2. Testes com IA: 13 agentes de IA especializados testam cenários de ataque específicos para aplicações web
3. Detecção de vulnerabilidades: identificamos problemas de segurança, de más configurações básicas a contornos complexos de autenticação
4. Relatórios acionáveis: explicações claras dos problemas encontrados e passos específicos para corrigir

Além do scan: cobertura de segurança completa

Além de encontrar vulnerabilidades, o scanner inclui:

• Verificação de RLS do Supabase: teste ponta a ponta das suas políticas de Row Level Security
• Monitoramento diário: scan contínuo para pegar problemas novos conforme seu app evolui

O que os desenvolvedores estão encontrando

Ranking dos problemas mais comuns entre as 5.711 vulnerabilidades encontradas em 1.430+ apps escaneados:

1. RLS ausente em SELECT - Crítico. Presente em 85% dos scans.
2. RLS ausente em INSERT/UPDATE/DELETE - Crítico. Presente em 51% dos scans. Normalmente sobe junto com uma política de SELECT funcional, por isso passa despercebido.
3. Chaves de API expostas - Crítico. Presente em 62% dos scans. OpenAI, Anthropic, Stripe e Resend são as quatro mais vazadas.
4. Contornos de autenticação - Alto. Presente em 45% dos scans. Normalmente um route guard só no frontend.
5. Validação de entrada ausente - Alto. Presente em 38% dos scans.
6. Bucket de Storage público - Alto. Presente em 34% dos apps Lovable que usam Storage.
7. Gates de feature paga só no frontend - Alto. Presente em 27% dos apps monetizados.
8. Service-role key no código client - Crítico. Raro (~4%), mas sempre é tomada total.

Começar é simples

Cole a URL do seu app em produção acima para receber um relatório de segurança com recomendações de correção. Há um teste gratuito de 14 dias.