Reeve Seu app do Lovable é seguro?
É seguro construir no Lovable? Normalmente sim. Quem decide é uma configuração do banco de dados feita no dia em que suas tabelas foram criadas.
Os logotipos são propriedade de seus respectivos donos e são exibidos apenas para indicar compatibilidade.
Em resumo
- Um app do Lovable costuma ser seguro do lado do código. Quem decide se os seus dados estão seguros é uma configuração do Supabase, tabela por tabela.
- Achar uma chave de API no seu app normalmente não é problema. Uma chave publicável pertence ali; sb_secret_… ou service_role não.
- O Supabase liga o Row Level Security nas tabelas feitas no Table Editor, mas não nas criadas por SQL, e é por SQL que um builder cria tabelas.
O Lovable leva você de uma ideia até um app funcionando mais rápido do que qualquer outra coisa, e a parte que ele cuida por você é justamente a que você nunca vê: o banco de dados, as tabelas, as regras sobre quem pode lê-las. Quando alguém diz que o seu app do Lovable "está vazando dados", a resposta em geral está aí, e não é um lugar que você consiga olhar de dentro do editor.
Aqui está o que guia após guia erra: o risco quase nunca é o código que o Lovable escreveu para você. É uma única configuração do banco, decidida no momento em que uma tabela foi criada, que a maioria dos textos pula ou descreve ao contrário.
O que o Lovable realmente constrói, e qual metade é pública
Duas metades, e só uma delas é privada.
Pense numa loja. O Lovable constrói para você uma vitrine: as páginas, os botões, os formulários, e essa vitrine é entregue inteira a cada visitante. Qualquer um consegue ler. Isso não é defeito; um navegador não exibe uma página que não recebeu. Atrás da vitrine existe um estoque, o seu banco no Supabase, que é um prédio separado com a própria fechadura.
O erro que sai caro é achar que a vitrine comanda o estoque. Ela não comanda. Tirar um botão do seu app é retirar uma placa, não trancar uma porta. O seu banco de dados é alcançável direto, pela internet, por qualquer um que tenha o endereço dele, e esse endereço está impresso na vitrine, porque é assim que o seu próprio app conversa com ele.
Uma chave no código do seu app do Lovable é problema?
Normalmente não. Depende inteiramente de qual chave é, e existem dois tipos que parecem quase idênticos.
Uma chave publicável diz a qual projeto um pedido pertence, e nada além
disso. O Supabase a chama de sb_publishable_… nos projetos novos e anon nos
antigos, e ela foi feita para ficar no seu app, onde qualquer um pode ler. Uma
chave secreta é o oposto: sb_secret_…, ou service_role nos projetos
antigos. Ela ignora todas as regras que você definiu e consegue ler e escrever em
toda linha de toda tabela.
As duas ficam lado a lado no painel do Supabase, têm o mesmo tamanho e se comportam igual enquanto você constrói. Copiar a errada é um único clique fora do lugar, e depois nada quebra, e é exatamente por isso que passa batido. Se quiser a versão longa de como diferenciar, escrevemos uma.
O que decide se estranhos conseguem ler os seus dados
O Row Level Security, uma chave por tabela no Supabase que decide linha a linha quem pode ver o quê. Com ela desligada, a sua chave publicável lê a tabela inteira. Com ela ligada e uma política escrita, lê apenas as linhas que a política permite.
Agora a parte que importa especificamente num app do Lovable. O Supabase liga o Row Level Security por padrão nas tabelas criadas no Table Editor do painel, aquele de clicar. Tabelas criadas rodando SQL não vêm com ele ligado e precisam ser ligadas de propósito.
Rodar SQL é como um builder cria tabelas para você.
Então o formato usual de um projeto do Lovable é um punhado de tabelas que você adicionou clicando, que estão protegidas, ao lado das tabelas que foram geradas para você, que talvez não estejam. As duas parecem idênticas no editor. Nenhuma vai reclamar. E ligar a configuração ainda não é a linha de chegada, porque uma tabela com Row Level Security ligado e uma política que permite todo mundo está aberta de um jeito que se lê como fechada.
Como conferir o seu próprio app do Lovable em uns dez minutos
Abra o Supabase e vá em Authentication → Policies. Percorra a lista de tabelas. Tudo que estiver marcado com Row Level Security desligado pode ser lido por qualquer um que tenha o endereço do seu projeto, que é público.
Confira a chave que o seu app entrega. No Supabase, vá em Settings → API. Se a chave que o seu app usa é a publicável, está certo e não há nada a fazer. Se alguma vez colaram uma chave secreta no seu projeto do Lovable, troque a chave lá primeiro: apagar do código não fecha a porta, porque o valor antigo continua existindo em cópias em cache do seu site.
Olhe os seus buckets de armazenamento. Tudo marcado como público pode ser listado e baixado por qualquer um, com ou sem link do seu app.
E depois olhe de fora. As conferências acima dizem o que está configurado; elas não dizem o que um estranho realmente alcança. É essa lacuna que o nosso scan gratuito preenche: ele lê o seu site no ar do jeito que qualquer visitante leria e te dá uma nota em uns 20 segundos, sem conta: escaneie seu app.
O que fazer
- A vitrine é pública por projeto. Tudo que o Lovable entrega a um navegador pode ser lido por qualquer um, e esconder não muda isso.
- Uma chave publicável no seu app está certa. Uma chave secreta (
sb_secret_…ouservice_role) é a que se troca hoje. - Tabelas feitas no Table Editor do Supabase já vêm com Row Level Security ligado. Tabelas criadas por SQL não, e é assim que um builder as cria.
- Ligar o Row Level Security é o passo um. Uma política que permite todo mundo deixa a tabela aberta enquanto o painel informa que ela está protegida.
- Tirar uma tela ou um botão do seu app do Lovable não muda nada do que o seu banco de dados vai responder.
A coisa mais rápida e útil que você pode fazer hoje é abrir Authentication → Policies no Supabase e ler a lista. Se alguma tabela disser que o Row Level Security está desligado, comece por ela, e se preferir percorrer tudo em forma de lista, o checklist de segurança de 10 minutos cobre o resto.
O que pode dar errado de verdade com um app do Lovable
Nada disso significa que você fez algo errado. São os efeitos colaterais normais de construir rápido. Aqui estão os que valem a conferida:
Uma chave secreta enviada para o navegador
Uma “chave secreta” é a senha mestra de um serviço que você usa: seu banco de dados, uma ferramenta de e-mail, uma API de IA. Ela deveria viver em um servidor. Às vezes uma escapa para o código que roda no navegador do seu visitante, onde qualquer um pode ler, e alguém poderia usá-la para chegar aos seus dados ou gerar custos em seu nome. A nuance: algumas chaves devem ser públicas (o Lovable e o Supabase as chamam de chaves “publishable” ou “anon”), e essas estão ok. O Reeve conhece a diferença, então uma chave segura nunca dispara um alarme falso.
Seu banco de dados deixado aberto (RLS do Supabase desligado)
Apps do Lovable geralmente guardam dados no Supabase. O Supabase tem uma chave de segurança chamada Row Level Security (RLS) que decide quem pode ler ou alterar cada linha. Se estiver desligada, suas tabelas podem ser legíveis, ou editáveis, por qualquer um que encontrar o endereço. É a diferença entre “meus dados são meus” e “minha lista de clientes é pública”, e é o problema mais comum em apps feitos com vibe coding.
Um arquivo .env ou de configuração exposto
O arquivo .env é onde um projeto guarda suas senhas e chaves. De vez em quando ele é publicado por engano junto com o app. Se estiver acessível, é um atalho direto para tudo o que é sensível. O Reeve verifica se o seu está acessível sem você saber.
Armazenamento de arquivos público
Se o seu app permite que as pessoas enviem arquivos (fotos, PDFs), eles vivem em “buckets” de armazenamento. Um bucket deixado público significa que qualquer um pode navegar ou baixar o que há dentro, então um envio destinado a uma pessoa pode acabar visível para todos. O Reeve verifica se os seus buckets são listáveis; ele nunca baixa os arquivos de ninguém.
Source maps deixados ligados
Um “source map” é um arquivo de bastidores que revela o código original do seu app. Útil durante o desenvolvimento, mas se for para produção entrega a estranhos uma cópia legível de como o seu app funciona, o que torna cada porta acima mais fácil de achar. Sozinho não é urgente, mas vale organizar.
Cabeçalhos de segurança ausentes e endpoints abertos
Pequenas configurações que dizem aos navegadores como proteger seus visitantes, além de se os endpoints de dados do seu app respondem a qualquer um ou a qualquer site. Individualmente pequenos; juntos, ampliam a brecha. O Reeve sinaliza os que estão faltando.
O que o Reeve é, e o que não é
O Reeve é uma verificação gratuita, somente leitura e por fora, como um inspetor que dá a volta no prédio e testa as portas. É rápida e pega os erros comuns de grande impacto. Não é uma auditoria de segurança completa, e uma nota limpa não é garantia. Significa que as portas óbvias estão fechadas.
O Lovable é uma ferramenta capaz, e a equipe dele adiciona sem parar barreiras de segurança; o Supabase também tem um consultor embutido que sinaliza problemas de RLS no painel. Ambos são de fato úteis. O que o Reeve acrescenta: você vive no Lovable, não no console do Supabase, e essas ferramentas falam em linguagem de desenvolvedor. O Reeve olha o seu app inteiro por fora, do jeito que um estranho faria, e diz o que encontra em palavras com as quais você pode agir. E se você preferir nem pensar nisso, podemos monitorar para você.
Quer que seja resolvido, não só verificado?
O Reeve Care continua monitorando seu app, faz backup dos seus dados e ajuda você a corrigir as coisas quando quebram, para que você siga criando em vez de se preocupar.
Conheça o Reeve CarePerguntas frequentes
Meu app do Lovable é seguro por padrão?
O Lovable te dá um ponto de partida sólido e melhora sem parar os padrões dele, mas “seguro por padrão” ainda depende de como o seu app está configurado, especialmente das regras do seu banco de dados no Supabase. A única forma de saber é verificar o que está de fato exposto, e é isso que a verificação gratuita do Reeve faz em cerca de 20 segundos.
Um app do Lovable pode vazar minhas chaves de API?
Pode acontecer, normalmente quando uma chave que pertence a um servidor acaba no código do front-end. Mas nem toda chave é um problema: algumas são feitas para ser públicas. O Reeve lê o código carregado do seu app, encontra todas as chaves e diz quais são seguras e quais precisam ser movidas.
O que é o RLS do Supabase e por que importa para o meu app do Lovable?
O RLS (Row Level Security) é a regra do Supabase sobre quem pode ver ou alterar cada linha dos seus dados. Se estiver desligado, suas tabelas podem ficar abertas para qualquer um. Como a maioria dos apps do Lovable usa Supabase, é a coisa mais importante de acertar, e o Reeve verifica isso sem nunca ler seus dados reais.
Verificar meu app do Lovable vai quebrar algo ou mudar meus dados?
Não. O Reeve só olha o que já é público por fora. Ele nunca faz login, nunca muda nada e nunca baixa seus arquivos. Somente leitura, como conferir se uma porta está trancada sem entrar.
O Lovable montou meu banco de dados. Isso quer dizer que está configurado com segurança?
Não automaticamente, e o motivo é bem específico. O Supabase liga o Row Level Security por padrão nas tabelas que você cria clicando no Table Editor. Tabelas criadas rodando SQL não ganham isso, e rodar SQL é como um builder cria tabelas para você. Então as tabelas que você fez na mão costumam estar protegidas e as que o Lovable fez talvez não.
Quais das minhas tabelas estão com Row Level Security ligado?
Abra o seu projeto no Supabase, vá em Authentication e depois Policies. Cada tabela do seu schema public aparece ali com o estado do RLS. Tudo que estiver como desligado pode ser lido por qualquer pessoa que tenha o endereço do seu projeto e a sua chave publicável, e as duas coisas estão dentro do seu app.
Achei uma chave no meu app do Lovable. Como sei se ela importa?
Veja de que tipo ela é. Uma chave publicável (chamada sb_publishable_ nos projetos novos do Supabase, ou anon nos antigos) pertence ao navegador e não é vazamento. Uma chave secreta, sb_secret_ ou a antiga service_role, ignora todas as regras que você definir e nunca deveria chegar a um navegador. Se achar essa, troque a chave no painel do Supabase antes de qualquer outra coisa.