O Lovable é seguro? O que vimos em 18.554 aplicativos Lovable

Você construiu algo no Lovable, funciona, e está prestes a colocar gente de verdade ali. Em algum momento dessa semana você digitou "lovable é seguro" numa busca, e o que voltou foi ou uma página sobre uma divulgação de segurança de 2025 ou um fornecedor te vendendo um escaneamento. Nenhuma das duas falava do aplicativo que você está prestes a publicar.

Eis o que a maioria dessas respostas erra: "o Lovable é seguro" são três perguntas vestidas de uma frase só, e a que decide se estranhos conseguem ler os dados dos seus usuários é a que quase ninguém mede.

Nós conseguimos medir. Entre 12 e 14 de agosto de 2026 passamos 30.998 aplicativos no ar pelas mesmas nove verificações externas que qualquer um pode rodar de graça na nossa página inicial, e 18.554 deles estavam publicados no Lovable. É a maior coorte que temos, três em cada cinco aplicativos que já escaneamos. Isso foi o que voltou para eles, e até onde a nossa vista alcança.

O Lovable é seguro?

Como plataforma, sim, e por uma margem maior do que esperávamos. O que o próprio Lovable entrega foi o mais limpo dos cinco construtores que medimos. Tudo que decidiu uma nota estava dentro do aplicativo que o dono tinha construído.

Pense numa loja com o estoque do outro lado da rua. O Lovable constrói a loja: as vitrines, o balcão, a placa. O estoque é do Supabase, e tem a própria fechadura na própria porta. O que a loja entrega a um passante é uma pergunta. O que o estoque entrega a qualquer um que chegue e peça é outra completamente diferente, e nenhuma arrumação na loja muda isso.

1. A plataforma. O Lovable publica seu aplicativo direito: certificado válido, domínio que não vence, nada vazando do build. Esta é a loja.
2. O agente. O código que a IA do Lovable escreve presta. Nenhum escaneamento externo enxerga a fiação, e este texto diz isso em vez de chutar.
3. O aplicativo que você publicou. O que um estranho alcança da calçada: uma chave no código que um navegador baixa, um bucket de armazenamento que lista os arquivos, uma tabela de banco que responde a quem perguntar.

Nossas verificações leem a terceira e duas partes da primeira. Na plataforma, o certificado era válido em todos os 18.486 aplicativos onde conseguimos ler um, e nenhum domínio de 18.554 estava perto de vencer. Do agente não temos nada a medir. Do aplicativo temos 18.554 respostas.

O que encontramos em 18.554 aplicativos Lovable

Nove verificações, de fora, sem login e sem acesso à conta de ninguém. Nunca lemos uma linha: onde um banco respondia, perguntamos quantas linhas ele entregaria e paramos ali. Nenhum aplicativo é nomeado aqui nem em nada que publicamos. Cada proporção abaixo é sobre os aplicativos em que a verificação respondeu, porque uma verificação que não conseguiu terminar é desconhecida e não aprovada, e essa regra é o motivo de os denominadores se moverem. O método e os dados estão no relatório.

As notas: 15.963 A, 370 B, 1.814 C, 402 D e 5 F. Nove aplicativos não tiveram nenhum achado.

Essa primeira linha é o motivo de "99 % dos aplicativos Lovable têm um problema de segurança" ser uma frase que você vai ler em algum lugar e deve ignorar. Os cabeçalhos de segurança do navegador são enviados por quem serve a sua página, e em seuapp.lovable.app isso é o Lovable, e por isso todo aplicativo naquele host recebe a mesma resposta. Eles valem a pena e não são do que um D é feito.

Tire essa linha e 15.453 dos 18.554 aplicativos não tinham mais nada. Os 3.092 restantes são o resto deste texto.

O que o Lovable acerta, e é quase toda a lista

Três dos números acima são os melhores que já anotamos em qualquer construtor, e os três são decididos pela plataforma e não por você.

Source maps. 225 de 18.553 aplicativos Lovable publicam os arquivos originais por trás do aplicativo, comentários inclusos. Isso é cerca de 1 em 80. No Base44 a mesma verificação dispara em 59 % dos aplicativos, e no Replit em 6 %. O build de produção do Lovable faz a coisa certa por padrão, então isso quase nunca é problema seu.

Cabeçalhos cross-origin. Zero aplicativos de 18.518 disseram a um site qualquer do mundo que ele podia chamar sua API, e zero permitiram isso com os cookies de login do visitante. Esse é o achado que com mais facilidade deixa outro site agir como o seu usuário, e no Lovable ele não apareceu uma vez sequer.

Arquivos privados perdidos. Zero aplicativos de 18.442 serviam um .env ou um .git/config a partir de uma URL comum. Um aplicativo Lovable não tem servidor próprio para configurar errado, então não há arquivo esquecido lá atrás.

Nada disso é prêmio de consolação. É a parte do trabalho em que você não precisou pensar e em que, na maioria dos outros construtores, alguém pensa.

O único número que importa: 2.017 de 3.553

Dos aplicativos Lovable cujo banco Supabase conseguimos de fato perguntar, 57 % entregaram linhas a uma requisição sem login nenhum.

Vale percorrer os denominadores, porque esse é o número que todo mundo cita e quase ninguém enquadra. De 18.554 aplicativos Lovable, 6.532 nomeavam um projeto Supabase no código que entregam. Desses, 3.553 responderam bem o bastante para podermos julgar, e os outros 2.979 não, então são desconhecidos e não limpos. Dos 3.553, 2.017 devolveram linhas a um estranho.

Em 373 desses aplicativos a tabela que respondeu tinha nome de gente: users, profiles, orders, messages. São 373 aplicativos, não 373 tabelas. Nos outros 1.644 era algo que não conseguimos nomear de fora: talvez um catálogo de produtos que sempre foi para ser público, talvez qualquer outra coisa.

Medido contra todos os aplicativos Lovable escaneados em vez do subconjunto que pudemos julgar, 2.017 de 18.554 dá cerca de 11 em cada 100. Guarde esse número por duas seções.

Por que isso cai no banco de dados e não no Lovable

Por causa de uma decisão de projeto que é correta, deliberada, e quase nunca explicada para a pessoa que ela afeta.

Um aplicativo Lovable não tem servidor próprio. A página no navegador do visitante fala direto com o Supabase, e é por isso que dá para construir a coisa toda numa tarde e por que tão poucos desses aplicativos têm uma rota de API aberta: não existe uma API sua para deixar aberta. Para isso funcionar, o endereço do seu banco e uma chave para ele precisam estar impressos dentro do aplicativo, onde qualquer um pode ler. Essa chave é a chave publicável, e ela ser pública está certo. Ela deve mesmo estar ali.

O que significa que a única coisa entre um estranho e a sua tabela users é uma configuração do Supabase por tabela chamada Row Level Security. Com ela ligada e uma policy escrita, a chave pública lê só as linhas que a policy permite. Com ela desligada, a chave pública lê a tabela.

Agora a parte que decide a maioria dos projetos Lovable. O Supabase liga o Row Level Security por padrão para tabelas que você cria clicando no Table Editor. Tabelas criadas rodando SQL não recebem isso, e rodar SQL é como um construtor cria tabelas para você. Então a forma comum de um projeto Lovable é: algumas tabelas feitas à mão, que estão protegidas, ao lado das que foram geradas, que podem não estar. As duas parecem idênticas. Nenhuma reclama. O aplicativo funciona perfeitamente dos dois jeitos, e esse é todo o problema: nada que você veja de frente diz qual das duas você tem.

A versão longa disso, com o SQL, está aqui, e o guia em linguagem simples para esta plataforma é seu aplicativo Lovable é seguro.

A policy que apaga o erro e deixa a tabela aberta

Ligar o Row Level Security é o passo um de dois, e é no passo dois que um assistente de IA faz de muito boa vontade a coisa errada.

Com a configuração ligada e sem policy escrita, o seu próprio aplicativo para de funcionar. Você recebe um erro, cola no chat, e volta algo que faz o erro sumir. Muitas vezes o que volta é uma policy que permite todo mundo, escrita como using (true). É uma policy válida. Ela atende ao requisito de existir uma policy. Ela permite cada linha a cada requisição.

O painel agora informa a tabela como protegida, o erro sumiu, seu aplicativo funciona, e a tabela está exatamente tão legível quanto antes. Temos um artigo inteiro sobre isso porque é a falha mais convincente da pilha toda: o RLS está ligado e sua tabela continua pública.

Se você já colou um erro de Row Level Security numa janela de chat e aceitou a primeira correção que fez o build passar, vá ler essa policy hoje.

CVE-2025-48757, e por que ela não é mais a sua pergunta

Ela é real, foi séria, e do lado do Lovable está fechada há mais de um ano. Também não é o que você deveria estar conferindo.

Em maio de 2025 o pesquisador de segurança Matt Palmer publicou a CVE-2025-48757, sobre aplicativos Lovable cujas tabelas no Supabase estavam sem Row Level Security ou com ele escrito de forma permissiva demais. Ele escaneou 1.645 aplicativos Lovable e achou 170 com bancos expostos. A resposta do Lovable foi adicionar uma verificação de segurança que roda antes de publicar e avisa sobre tabelas desprotegidas.

E aqui vai a leitura honesta, e é por isso que a CVE é o enquadramento errado. Aquela divulgação achou cerca de 10 aplicativos expostos em cada 100. Dezesseis meses depois, numa coorte onze vezes maior, achamos cerca de 11 em cada 100. Os denominadores não são idênticos e nenhuma das duas amostras é a internet inteira, então tome as duas como a mesma ordem de grandeza e não como uma comparação precisa. A direção está clara o bastante: a taxa não caiu.

Isso não é uma correção que falhou. É sinal de que nunca foi de fato uma vulnerabilidade de produto. É uma configuração nas suas próprias tabelas, no seu próprio projeto Supabase, que ninguém mais consegue ligar por você. Uma correção não alcança isso, e é exatamente por isso que uma verificação que você mesmo roda alcança.

Do que as 822 chaves eram feitas de verdade

Quase todas estavam certas, e um scanner que te dissesse o contrário estaria te ensinando a ignorá-lo.

822 dos 18.554 aplicativos Lovable tinham algo com formato de chave no código que um visitante baixa. Lido como uma lista de formatos, isso é 4 % dos aplicativos "vazando segredos". Lido como o que cada chave de fato consegue fazer, fica assim:

As 727 chaves do Google são o motivo de classificarmos em vez de só reconhecer formatos. Uma chave do Google Maps num navegador está onde deve estar, e a correção é restringi-la ao seu próprio domínio em vez de entrar em pânico.

As quatro últimas linhas são as que importam, e são raras: 30 aplicativos de 18.554. São também os achados que custam dinheiro sozinhos, e costumam aparecer como uma fatura que chega antes de alguém notar. Dois detalhes para registro. As três chaves service_role do escaneamento inteiro de 30.998 aplicativos estavam em aplicativos Lovable, e dois dos três segredos da Stripe em vivo também. Uma chave service_role no navegador torna cada policy de Row Level Security do seu projeto irrelevante em uma linha, e é por isso que é o único achado que classificamos como crítico de imediato e o que vale rotacionar no mesmo dia.

Distinguir os dois tipos leva cerca de um minuto, e escrevemos o guia.

Os 768 buckets de armazenamento que ninguém quis abrir

Um bucket do Supabase marcado como público não serve só os arquivos que o seu aplicativo referencia. Ele também lista cada arquivo lá dentro para quem perguntar.

768 dos 16.565 aplicativos Lovable verificáveis tinham pelo menos um bucket que listava o conteúdo. O motivo é o mesmo das tabelas legíveis: deixar um bucket público é como você faz uma imagem aparecer, funciona na hora, e depois nada te diz que a listagem veio junto. Notas fiscais enviadas, fotos de documentos e avatares de usuários acabam todos no mesmo lugar. O que um bucket público realmente expõe cobre a correção, que são URLs assinadas e não um bucket privado do qual você depois não consegue ler.

A verificação de cinco minutos no seu aplicativo Lovable

Cada item é uma página que você abre. Use uma janela anônima para que o seu próprio login não responda no lugar de um estranho.

1. Supabase → Authentication → Policies. Percorra a lista. Qualquer tabela mostrando Row Level Security desativado é legível por quem tiver o endereço do seu projeto, que está impresso no seu aplicativo.
2. Leia as policies das tabelas que estão com ele ligado. Se uma delas permite todo mundo, a tabela está aberta e o painel continua chamando de protegida.
3. Supabase → Storage. Qualquer bucket marcado como público lista os arquivos para qualquer um. Veja o que tem dentro antes de decidir que está tudo bem.
4. Supabase → Settings → API. Confirme que a chave que o seu aplicativo entrega é a publicável. Se alguma chave secreta já foi colada no projeto, rotacione ali antes de apagar do código, porque o valor antigo continua funcionando até você fazer isso.
5. Ou deixe o escaneamento fazer. Ele roda esses quatro de fora e mais cinco, leva uns 20 segundos, não pede conta, e mostra uma nota e o que a produziu: escanear seu aplicativo.

Se você prefere percorrer a superfície toda como uma lista, o checklist de segurança de 10 minutos cobre o que vale confirmar em qualquer aplicativo recém-lançado, e qualquer um consegue ler seu banco de dados Supabase é o teste para fazer se você só for fazer uma coisa.

Seu aplicativo muda toda vez que você publica

Um escaneamento que você rodou mês passado descreve o aplicativo do mês passado, e no Lovable esse é um mês mais curto que na maioria.

Publicar é um clique, então uma mudança está no ar assim que você a aceita. Não existe passo de deploy entre você e a internet para pegar uma tabela adicionada hoje de manhã com Row Level Security desligado, ou uma chave colada no chat à meia-noite para passar de um build que falhava. Cada um dos 2.017 bancos expostos que achamos era de alguém cujo aplicativo funcionava perfeitamente.

Reeve Monitor é a versão deste texto que roda sozinha. Ele repete as nove verificações toda hora em até três aplicativos, olha a cada 60 segundos se o aplicativo responde, te avisa quando um resultado muda em vez de esperar você olhar, e manda um relatório mensal. Custa $12 por mês no preço de tabela, com sete dias grátis antes de cobrar; a página de preços às vezes fica abaixo do número daqui e nunca acima.

Se o seu aplicativo Lovable usa Supabase, e 6.532 dos 18.554 escaneados usam, a outra metade do problema é a cópia. Uma tabela exposta é algo que um estranho consegue ler. Um agente com acesso ao banco, ou uma migração que rodou ao contrário, é algo que consegue apagar, e o backup diário do próprio Supabase no plano gratuito não é algo que você consiga restaurar sozinho. O Reeve Care tira toda noite uma cópia criptografada do seu banco Supabase, guarda onde o seu projeto não alcança, verifica que cada cópia realmente restaura, e te dá uma restauração em um clique quando precisar. Tudo que o Monitor faz está incluído. O Care custa $49 por mês no preço de tabela para um aplicativo, com os mesmos sete dias grátis.

O formato dessa segunda falha, contado por quem passou por ela, está em o dia em que um agente de IA apagou um banco de produção. Nenhuma das nove verificações deste artigo teria ajudado ali. Uma cópia teria.

O que fazer esta semana

O Lovable fez bem a metade dele. Os 2.017 são a metade que é sua, e é uma configuração e não uma reescrita. Se o que você quer é a comparação entre construtores, qual construtor de aplicativos com IA é o mais seguro tem a tabela dos cinco.