Escaneamento de segurança do Lovable: o que ele não prova

Você clica em Publish no seu aplicativo Lovable e, antes de ele sair, um escaneamento roda. Alguns segundos depois ele volta limpo, ou volta com uma lista, e nos dois casos você está com um resultado que não tem como julgar. É só isso? Dá para colocar gente de verdade em cima?

E esta é a parte que vale saber antes de decidir: o escaneamento de segurança do Lovable e um escaneamento do seu aplicativo publicado leem dois objetos diferentes. Um lê as fechaduras e a fiação. O outro chega perto e abaixa a maçaneta. Os dois valem, e só o segundo faz o que cada visitante do seu aplicativo faz o dia inteiro.

O Lovable verifica meu aplicativo em busca de problemas de segurança?

Sim, e são dois. Os dois são gratuitos.

O Quick scan roda sozinho toda vez que você publica e termina em segundos. O Deep scan lê todo o código do seu aplicativo e você mesmo dispara. Os dois leem o seu projeto por dentro: as configurações do seu banco, as regras de acesso nas suas tabelas, a sua árvore de dependências, o seu código.

Tudo o que vem abaixo foi lido na documentação de segurança do próprio Lovable em 24 de setembro de 2026. Esse recurso mudou mais de uma vez em um ano, então olhe a data de qualquer artigo que descreva ele, este incluído.

O que o escaneamento de segurança do Lovable checa

Três áreas, como um conjunto fixo de verificações, em segundos, a cada publicação.

A documentação do Lovable chama elas de revisão do banco de dados, auditoria de dependências e verificação de servidor MCP. A revisão do banco é a que importa neste artigo, e a descrição dela merece uma leitura devagar: cobre tabelas sem controle de acesso por registro, ou seja, sem Row Level Security, além de regras de acesso que deixam todo mundo passar e a proteção contra senhas vazadas desligada. A auditoria de dependências procura vulnerabilidades conhecidas nos seus pacotes npm. A verificação de MCP procura um servidor MCP que o seu aplicativo exponha sem autenticação.

Os achados voltam agrupados por área e rotulados como Critical, Warning ou Info. O escaneamento dispara automaticamente pela caixa de publicação, e você também pode iniciar ele na visão Security do projeto.

Alguns textos chamam isso de Basic scan. O botão na visão Security hoje diz Run quick scan, então se um artigo e a sua tela discordarem sobre o nome, a sua tela é a atual.

O que o Deep scan acrescenta

Ele lê todo o código do seu aplicativo, e não se dispara sozinho.

O Deep scan inclui tudo do Quick scan e depois olha a sua própria lógica, as suas permissões e os seus dados. O Lovable lista sete áreas: controle de acesso e autorização, endpoints sem autenticação e passíveis de abuso, entrada insegura e injeção, segredos e credenciais vazados, pagamentos e cobrança, autenticação e segurança de contas, e dados pessoais e sensíveis expostos. Ele também é gratuito.

A frase da documentação para agir de verdade é esta: o Deep scan não roda automaticamente enquanto você trabalha. Ele roda quando você roda. Um projeto em que nunca dispararam um nunca teve o código lido, por mais vezes que tenha sido publicado, e a caixa de publicação não vai te contar isso. Espaços de trabalho Enterprise podem agendar Deep scans em projetos escolhidos pelo Workspace Security center, e essa é a única configuração em que isso acontece sem alguém lembrar.

O Lovable também pode tentar correções, enquanto você constrói ou pelo Try to fix all na visão Security. Leia o que uma correção mudou antes de aceitar. O conserto que faz um erro de row level security sumir é muito seguidamente uma política que deixa todo mundo passar, e essa política cumpre a verificação e deixa a tabela aberta.

A crítica de 2025, e o que mudou

A primeira versão dessa verificação dizia que uma política existia. Ela não dizia se a política funcionava, e o pesquisador que achou o problema original escreveu isso ele mesmo na época.

Em maio de 2025 Matt Palmer publicou a CVE-2025-48757, sobre aplicativos Lovable cujas tabelas Supabase estavam sem row level security ou com ele escrito de forma larga demais. A resposta do Lovable foi a verificação antes de publicar. O próprio texto de Palmer descreveu o limite dela num parêntese:

O recurso Publish do Lovable ajuda a garantir que as políticas de RLS estejam ativadas em todas as tabelas e avisa quando não estão (mas não indica necessariamente se elas são suficientes).

Essa lacuna tem resposta na documentação atual, que nomeia as regras de acesso que deixam todo mundo passar como algo que a revisão do banco sinaliza. Nada neste artigo testa essa afirmação. Se você quiser testar, crie uma tabela descartável com uma política que deixa todo mundo passar e veja se o escaneamento nomeia ela. A versão longa da CVE está em o Lovable é seguro.

O que um escaneamento por dentro não prova

Se o seu aplicativo no ar entrega linhas para alguém que não fez login.

Uma fechadura pode estar instalada, registrada e correta na planta, e a porta abrir do mesmo jeito. Uma política é uma declaração sobre o que deveria acontecer; o que decide o que acontece é uma requisição. Três jeitos de uma regra constar como presente e a tabela responder assim mesmo:

• A política deixa todo mundo passar. Escrita como using (true), é uma política válida, cumpre a exigência de que exista uma, e devolve toda linha para todo chamador.
• A política cobre a leitura e mais nada. O select é verificado, o insert, o update e o delete nunca foram escritos, então qualquer um consegue escrever numa tabela que ninguém consegue ler inteira.
• A condição bate com mais gente do que deveria. Ela tinha que nomear um cliente só e nomeia todo visitante logado, ou todo visitante.

Agora a parte que decide como você deveria ler um resultado verde. De fora, esses três e uma tabela sem proteção nenhuma dão a mesma resposta, que são linhas. Os seus usuários não distinguem. Ninguém mais que abrir o seu aplicativo distingue também.

Entre 12 e 14 de agosto de 2026 passamos as mesmas nove verificações externas em 30.998 aplicativos no ar, e 18.554 deles estavam publicados no Lovable. Dos aplicativos Lovable que nomeavam um projeto Supabase, 3.553 nos responderam com clareza suficiente para julgar, e 2.017 deles devolveram linhas para uma requisição que não levava login nenhum. O método e cada denominador estão no relatório.

Uma ressalva honesta sobre esse número. Nós estávamos na calçada, e não temos vista nenhuma para dentro desses projetos. Podemos relatar o que 2.017 aplicativos publicados responderam. Não podemos relatar quantos deles tinham rodado um escaneamento, nem o que ele disse a eles.

O seu próprio aplicativo responde à mesma pergunta em uns 20 segundos, e você não precisa acreditar na nossa palavra sobre de que lado dos 2.017 ele cai: escanear seu aplicativo. O escaneamento pergunta a cada tabela quantas linhas um chamador sem login receberia, lê o número e para por aí, sem puxar uma linha sequer.

O que um escaneamento de fora não enxerga

Abaixar a maçaneta não te diz nada sobre um cômodo sem porta para a rua, e existem quatro desses.

A sua árvore de dependências npm não está na página que um navegador baixa. O seu código de servidor, incluindo edge functions e se uma rota confere quem está chamando, roda num lugar que nunca alcançamos. Uma tabela que o seu front-end nunca nomeia é invisível para nós, porque achamos nomes de tabela no código que o seu aplicativo entrega mais uma lista curta de nomes comuns, então uma tabela que não aparece em lugar nenhum do navegador e que ninguém adivinharia não chega a ser perguntada. E um servidor MCP não é algo que uma requisição de página encontre.

Os dois escaneamentos do Lovable juntos leem os quatro. O nosso escreve "Não foi possível verificar" quando não conseguiu responder uma pergunta, em vez de uma marca de certo.

A linha sobre o que o seu aplicativo publicado entrega a um estranho é o motivo para rodar os dois, e é a linha em volta da qual o nosso escaneamento foi construído. A versão geral de onde a vista de fora termina está em o que um escaneamento por URL não pega.

Os dois, e nesta ordem

O escaneamento por dentro antes de publicar, o de fora depois, porque essa é a ordem em que as duas coisas acontecem.

1. Deixe o Quick scan rodar na publicação e depois leia. São alguns segundos, e vai acontecer de qualquer jeito. Passar direto pela caixa é o jeito mais comum de um achado Critical chegar em produção.
2. Dispare um Deep scan antes de qualquer coisa real ir ao ar, e de novo depois de acrescentar login, pagamentos ou qualquer tabela que guarde pessoas. Sozinho ele não roda.
3. Publique.
4. Escaneie o endereço publicado de fora. O nosso lê o seu aplicativo no ar do jeito que um visitante lê, leva uns 20 segundos, não precisa de conta e nomeia as verificações que não conseguiu terminar: escanear seu aplicativo.

Nessa sequência existe uma brecha, e é com ela que vale planejar. O Quick scan roda quando você publica. A maior parte do que abre uma tabela não passa pela publicação: você muda uma configuração no painel do Supabase, aceita à meia-noite uma política que um assistente escreveu numa janela de chat, cria uma tabela hoje de manhã e a tela que lê ela sai na quinta. Nada disso é uma publicação, então nada disso dispara um escaneamento, e o Deep scan nunca ia rodar sozinho de qualquer forma.

Reeve Monitor faz a metade de fora nos dias em que você não lembra. Ele repassa as nove verificações a cada hora em até três aplicativos, olha se o seu aplicativo está respondendo, te avisa quando um resultado muda em vez de esperar você ir olhar, e manda um relatório no fim de cada mês.

Lendo um resultado verde

Um resultado limpo quer dizer que toda pergunta que aquele escaneamento conseguia fazer voltou limpa no dia em que você rodou. Isso vale alguma coisa, e não é um veredito sobre o seu aplicativo.

O Lovable coloca a mesma ressalva na própria documentação: as ferramentas ajudam a identificar problemas comuns de segurança e não conseguem garantir segurança completa. O nosso carrega ela também, porque uma verificação externa automática não é uma auditoria e uma lista de achados vazia não é uma garantia.

A única regra para quando os dois discordam: se o escaneamento por dentro está limpo e um de fora diz que uma tabela respondeu a uma requisição sem login, aja pela resposta de fora. É a resposta que os seus usuários recebem, e é a resposta que qualquer outra pessoa recebe. Vá ler a política daquela tabela.

Se o seu aplicativo está no Supabase, o passo a passo em linguagem simples para esta plataforma é o seu aplicativo Lovable é seguro, e as verificações escritas como comandos para você mesmo rodar estão em o verificador de segurança do Supabase.

O que fazer esta semana

Se o seu aplicativo Lovable usa Supabase, abra uma janela anônima e passe pela lista em Authentication e Policies antes de sexta. Qualquer um consegue ler seu banco de dados Supabase é o mesmo teste escrito como comandos para colar num terminal.