POR QUE TODO PROJETO LOVABLE PRECISA DE TESTE DE SEGURANÇA

O risco escondido no desenvolvimento com IA

Me entenda bem — o Lovable é incrível. Dá para construir aplicações inteiras em horas que antes levavam semanas. Mas tem uma coisa de que ninguém fala: quando você está se movendo 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. Elas deixam passar os padrões e vulnerabilidades que emergem quando uma IA escreve boa parte da sua aplicação. Por isso construímos o Scanner de Segurança Lovable.

O que torna projetos Lovable diferentes?

Assistentes de código com IA como o Lovable revolucionaram a forma de construir aplicações web. Mas também introduzem considerações de segurança únicas 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

Depois de escanear muitos apps Lovable, identificamos vários padrões comuns que desenvolvedores precisam observar:

Os 6 fluxos de vibe coding que mais quebram

“Vibe coding” — entregar um app funcionando conversando com uma IA e nunca lendo metade do código gerado — tem um formato previsível. Em mais de 1.430 scans Lovable, os mesmos seis fluxos respondem pela maioria dos criticals. Se você endurecesse só esses, eliminaria a maior parte dos bugs que impactam produção em apps gerados por IA.

Cada um desses fluxos produz o mesmo sintoma nos nossos relatórios: UI limpa, app funcionando e um achado crítico no endpoint por trás. O scanner percorre os seis automaticamente. Para mais contexto sobre 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

Depois de escanear 1.430+ aplicações Lovable, uma vulnerabilidade se destaca acima de todas: políticas de Row Level Security (RLS) ausentes ou mal configuradas. Esse problema continua disparando em projetos Lovable novos.

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 não é um único interruptor. É uma política por operação, por tabela. Deixe uma escapar e a superfície de ataque continua escancarada. Nosso scanner roda as quatro em cada tabela pública que descobre:

O erro comum: desenvolvedores testam SELECT, veem que está trancado e sobem. Escritas ficam escancaradas. Vemos isso em ~30% dos apps que “habilitaram RLS”.

Políticas quebradas que parecem corretas

Estas são as políticas de RLS que mais sinalizamos — elas compilam, o app funciona e a tabela ainda está 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 — os padrões que seguram quando testados:

-- 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 — é mais difícil de configurar errado e mais fácil de auditar.

Teste seu RLS em 30 segundos

Você não precisa do nosso scanner 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 — essas ignoram RLS inteiro. Qualquer erro lógico dentro de uma função é leitura/escrita completa do banco.
• JWTs vazados — se o JWT de um usuário logado vaza (XSS, um gist público, uma captura de tela), o RLS felizmente serve ao atacante o que aquele usuário veria.
• Storage — o Storage tem regras parecidas com RLS por bucket e por objeto. São configuradas separadamente e, em apps Lovable, costumam ficar como “public bucket”.
• 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

Nosso scanner foi feito especificamente para entender a arquitetura do Lovable. Isto é o que acontece quando você escaneia 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

O Scanner de Segurança Lovable não é só sobre encontrar vulnerabilidades. É uma solução de segurança completa:

• Testes multi-navegador: garante que seu app funcione com segurança em navegadores diferentes
• 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
• Prevenção de vazamento de dados: detecta informação sensível que pode estar exposta
• Proteção de tokens de API: evita exposição acidental de credenciais sensíveis
• Checks de prontidão para lançamento: validação abrangente de segurança pré-deploy

O que os desenvolvedores estão encontrando

Entre as 5.711 vulnerabilidades encontradas em 1.430+ apps escaneados, este é o ranking dos problemas mais comuns:

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

Você não precisa ser especialista em segurança para proteger seus projetos Lovable. Cole a URL do seu app em produção acima. Em minutos, você recebe um relatório abrangente de segurança com recomendações acionáveis.

Comece com um teste gratuito de 14 dias. Sem setup longo. Só insights de segurança reais para aplicações reais.