Seu app feito no Lovable é seguro? Checklist antes de lançar

Checklist de segurança para app feito no Lovable: RLS no Supabase, autenticação, chaves, validação no servidor, storage, rate limiting e LGPD antes de lançar.

Um app feito no Lovable pode ser seguro, mas não fica seguro sozinho. O Lovable gera código funcional e roda uma verificação antes de publicar, mas quem garante que um usuário não lê os dados de outro são as regras do banco de dados (o RLS do Supabase), o lugar onde ficam as chaves e a validação feita no servidor. Se você vai colocar dados reais de clientes no ar, passe pelo checklist abaixo antes.

Ele vale também, com pequenas adaptações, para apps feitos com Bolt.new, Replit Agent ou qualquer projeto que use Supabase direto do navegador.

Por que isso importa: como um app do Lovable funciona por baixo

Em apps do Lovable com backend (seja o Lovable Cloud, que roda sobre o Supabase, seja um projeto Supabase conectado por você), a arquitetura costuma ser esta:

1. O front-end (React) roda no navegador do usuário.
2. Ele conversa direto com o banco de dados, usando uma chave pública.
3. O banco decide, linha por linha, o que aquela pessoa pode ver e alterar.

Isso é ótimo para velocidade de desenvolvimento. Mas significa que não existe um servidor no meio filtrando as requisições. Qualquer pessoa pode abrir o DevTools, copiar a URL e a chave pública do projeto e fazer consultas por conta própria. Se o banco não estiver protegido, ela vê tudo.

Esse risco tem histórico público: em 2025, o pesquisador Matt Palmer relatou que cerca de 170 de 1.645 apps da vitrine do Lovable expunham tabelas por regras de acesso mal configuradas, caso registrado como CVE-2025-48757. Desde então, o Lovable reforçou a verificação de segurança antes da publicação, que usa o Security Advisor do Supabase. É um avanço, mas não dispensa a revisão abaixo.

Checklist de segurança antes de lançar

1. RLS ligado em todas as tabelas

O Row Level Security é o porteiro do banco. Com ele ligado e sem nenhuma regra, ninguém acessa nada pela API. Com ele desligado, a tabela fica aberta para quem tiver a chave pública.

• Todas as tabelas do schema public estão com RLS ativado.
• Nenhuma policy usa using (true) em tabela com dado pessoal ou privado.
• Policies de insert e update têm with check, impedindo que alguém grave dados em nome de outro usuário.
• Views que leem tabelas protegidas usam security_invoker = true (as views ignoram o RLS por padrão).

Exemplo de tabela de pedidos em que cada usuário só vê os próprios:

alter table public.pedidos enable row level security;

create policy "usuario ve os proprios pedidos"
on public.pedidos for select
to authenticated
using ( (select auth.uid()) = user_id );

create policy "usuario cria pedido para si mesmo"
on public.pedidos for insert
to authenticated
with check ( (select auth.uid()) = user_id );

Se RLS é novidade para você, leia Supabase RLS explicado, com os erros mais comuns e como testar.

2. Autenticação configurada de verdade

• Confirmação de e-mail ativada (evita contas com e-mail de terceiros).
• URLs de redirecionamento do login restritas ao seu domínio.
• Recuperação de senha testada de ponta a ponta.
• Papéis como "admin" guardados em tabela própria ou em app_metadata, nunca em user_metadata, que o próprio usuário consegue alterar.
• A área de admin é protegida no banco, não só escondida no menu.

Atenção: esconder um botão não é controle de acesso. Se a regra "só admin pode apagar" existe só na tela, qualquer usuário logado consegue apagar chamando a API direto.

3. Chaves e variáveis de ambiente

O Supabase está migrando das chaves antigas anon e service_role para as novas publishable (sb_publishable_...) e secret (sb_secret_...). A regra continua a mesma:

• Procure no código por sk-, sb_secret, service_role, secret e api_key.
• Segredos ficam nos secrets das Edge Functions ou no painel de variáveis do backend, não em arquivos do front-end.
• O repositório no GitHub não tem arquivo .env com segredos commitados. Se tiver, troque as chaves: apagar o arquivo não apaga o histórico.

4. Validação no servidor

Tudo que o usuário envia pode ser manipulado. Valide no backend:

• Preços e totais calculados no servidor, nunca vindos do navegador.
• Cupons, limites de plano e permissões verificados no banco ou em Edge Functions.
• Campos com tamanho e formato limitados (constraints no banco ajudam muito).
• Webhooks de pagamento verificam a assinatura do gateway antes de liberar qualquer coisa.

Um exemplo simples de constraint que protege mesmo se a tela falhar:

alter table public.pedidos
  add constraint quantidade_valida check (quantidade between 1 and 100);

5. Storage (arquivos)

O Supabase Storage tem buckets públicos e privados. Em bucket público, qualquer pessoa com a URL do arquivo consegue baixá-lo.

• Documentos, comprovantes, fotos de perfil privadas e anexos ficam em bucket privado.
• Arquivos privados são entregues com URLs assinadas e com prazo de validade.
• Há policies em storage.objects limitando quem envia e quem apaga arquivos, por exemplo usando uma pasta com o ID do usuário.
• Tamanho máximo e tipos de arquivo permitidos estão configurados no bucket.

6. Rate limiting e abuso

Rate limiting é limitar quantas vezes alguém pode fazer uma ação em um intervalo de tempo. Sem isso, um robô pode criar milhares de contas, testar senhas ou chamar sua API de IA sem parar.

• Revise os limites de autenticação no painel do Supabase (envio de e-mails, tentativas de login).
• Ative CAPTCHA em cadastro e login se o app for público.
• Edge Functions que chamam APIs pagas exigem usuário logado e têm limite por usuário.
• Alertas de gasto configurados no provedor de IA, no banco e na hospedagem.

7. LGPD

Se o app coleta dados pessoais de pessoas no Brasil, a Lei Geral de Proteção de Dados (Lei 13.709/2018) se aplica. Não é preciso ser uma grande empresa para isso. O mínimo:

• Política de privacidade clara, dizendo quais dados você coleta e por quê.
• Coleta apenas do necessário (se não usa CPF, não peça).
• Forma de o usuário pedir acesso, correção e exclusão dos dados.
• Saber onde os dados ficam guardados, inclusive a região do servidor.
• Plano mínimo para incidente: quem avisa, como avisa, como troca as chaves.

Dica: dados sensíveis, como saúde, biometria e origem racial, têm regras mais rígidas na LGPD. Se o seu app lida com eles, procure orientação jurídica específica.

8. Teste como se fosse o atacante

Antes de lançar, faça um teste simples:

1. Crie dois usuários de teste, A e B.
2. Logado como A, crie alguns registros.
3. Logado como B, tente ler, editar e apagar os registros de A (pela tela e chamando a API).
4. Deslogado, tente ler qualquer tabela usando só a chave pública.

Se alguma dessas tentativas funcionar, você achou um problema antes de um estranho achar.

O que a verificação do Lovable cobre (e o que não cobre)

Segundo o próprio Lovable, a verificação antes da publicação usa o Security Advisor do Supabase para apontar problemas como tabelas sem RLS. A empresa também descreve um revisor de segurança com IA para pontos que a verificação básica não pega, como segredos no código e funções desprotegidas.

Use as duas coisas. Mas entenda o limite: uma ferramenta automática sabe se existe uma policy, não se ela faz sentido para o seu negócio. Uma regra "usuário logado pode ler todos os pedidos" passa em muitas verificações e ainda assim expõe dados de todos os clientes.

Resumo do checklist

1. RLS ligado em todas as tabelas, sem true genérico.
2. Login com confirmação de e-mail e papéis fora do user_metadata.
3. Nenhuma chave secreta no front-end ou no repositório.
4. Preços, permissões e regras validados no servidor.
5. Buckets privados para arquivos privados.
6. Rate limiting, CAPTCHA e alertas de gasto.
7. LGPD: política, mínimo de dados, canal para pedidos.
8. Teste com dois usuários antes de lançar.

Quer entender o panorama completo? Veja também os problemas que ninguém conta sobre sites feitos com IA.

Quer que alguém revise antes de você lançar?

Se o checklist levantou mais dúvidas do que respostas, a Mobgeek faz o resgate de projetos feitos com IA: auditoria de segurança, correções, deploy, performance e SEO, com a auditoria a partir de R$ 1.990. Você também pode contar o seu caso e pedir um orçamento.