RLS no Supabase: como conferir se o seu app feito no Lovable está protegido

Para saber se o seu app feito no Lovable está protegido, confira o RLS no Supabase: ele precisa estar ligado em cada tabela com dados de usuários, e cada regra de acesso (a policy) deve liberar só o dono do dado. Dá para conferir em poucos minutos no painel, pelo Security Advisor e pela tela de Policies.

Se o app guarda dados de clientes, é bem provável que eles estejam no Supabase, e esse detalhe decide se estão protegidos ou abertos para qualquer pessoa. Veja o que é o RLS, como conferir e qual é o erro mais comum.

Por que isso importa

Num app feito com Lovable, o navegador do usuário conversa direto com o banco de dados do Supabase. Para isso, o app carrega uma chave pública (a publishable key, ou anon key nos projetos mais antigos). Essa chave fica visível no navegador de propósito, e isso é normal. O que impede alguém de usar essa chave para ler a tabela inteira de clientes é o RLS.

Quando o RLS falta ou está mal configurado, o problema é real. Em maio de 2025, uma análise de 1.645 apps feitos no Lovable e exibidos no site da empresa encontrou 170 que permitiam a qualquer pessoa acessar dados dos usuários, como nomes, e-mails, informações financeiras e chaves de API (Semafor). O caso foi registrado como CVE-2025-48757, e a causa apontada foram políticas de acesso ao banco insuficientes. A Lovable contesta o registro, argumentando que proteger os dados é responsabilidade de cada projeto (Tenable), o que só reforça: quem cuida dos dados é o dono do app.

O que é RLS no Supabase e o que é uma policy

RLS (Row Level Security, ou segurança por linha) é um recurso do PostgreSQL, o banco que roda por trás do Supabase. Com ele ligado, cada tabela passa a ter um porteiro: nenhuma linha sai ou entra sem que uma regra autorize.

Essas regras se chamam policies. Cada policy diz, em linguagem de banco de dados, algo como "um usuário logado só pode ver os pedidos em que ele é o dono". Elas têm duas partes principais:

• using: filtra quais linhas existentes o usuário pode ver, alterar ou apagar.
• with check: valida as linhas novas ou alteradas, por exemplo, impedindo alguém de criar um registro em nome de outra pessoa.

Segundo a documentação do Supabase, uma tabela num schema exposto sem RLS pode ser lida e alterada por quem tiver acesso à API. E, com o RLS ligado mas sem nenhuma policy, nada passa pela chave pública: o app simplesmente para de mostrar os dados.

Passo a passo para conferir no painel

1. Rode o Security Advisor

No painel do seu projeto no Supabase, abra a área Advisors e escolha Security Advisor. Ele faz uma checagem automática e lista problemas por gravidade. Preste atenção especial nestes avisos (lista oficial):

• RLS disabled in public (gravidade ERROR): existe uma tabela pública sem RLS. É o problema mais grave.
• Policy exists RLS disabled: há policies escritas, mas o RLS está desligado, então elas não valem nada.
• Permissive RLS policy: uma policy com condição sempre verdadeira, como using (true).
• Sensitive columns exposed: uma tabela com colunas que parecem sensíveis (senhas, documentos) acessível sem RLS.

Alguns avisos podem ser intencionais, como uma tabela de produtos que deve ser pública. O importante é que cada um tenha uma resposta consciente.

2. Confira tabela por tabela

No Table Editor, o painel mostra se cada tabela está com o RLS ativo. O RLS não é uma configuração global: ele precisa estar ligado em cada tabela. Tabelas criadas pelo SQL Editor ou por migrations geradas pela IA podem ter ficado sem ele.

3. Leia as policies

Na tela de Policies, as regras aparecem agrupadas por tabela. Para cada uma, pergunte: "quem pode fazer o quê, e em quais linhas?". Se a resposta for "qualquer pessoa, em todas" numa tabela com dados de clientes, há um problema.

O erro mais comum: a policy que libera tudo

O RLS é ligado, o app para de mostrar os dados, e a solução mais rápida (às vezes sugerida pela própria IA) é esta:

create policy "Enable read access for all users"
on public.orders for select
using (true);

O using (true) significa "toda linha é permitida". O Security Advisor fica com o RLS "ativo", mas na prática a tabela continua aberta. Uma versão segura limita o acesso ao dono do registro e ao papel de usuário logado:

create policy "Users can view their own orders"
on public.orders for select
to authenticated
using ( (select auth.uid()) = user_id );

Aqui, auth.uid() é o ID de quem está logado, e user_id é a coluna que guarda o dono do pedido. A mesma lógica vale para insert, update e delete, cada um com sua policy.

Outro alerta do Supabase: não use user_metadata como base de permissão (por exemplo, "se o usuário for admin"), porque o próprio usuário consegue editar esse campo. E o RLS só funciona se a chave secreta continuar no servidor: a service_role ignora todas as policies. Veja como achar e resolver chaves de API expostas no navegador.

Como testar com segurança no seu próprio projeto

Teste apenas o seu app, de preferência com usuários de teste criados por você.

1. Crie dois usuários de teste (por exemplo, Ana e Bruno) e cadastre dados para cada um.
2. Use a impersonação do painel. O Supabase permite, no Table Editor e no SQL Editor, rodar consultas "como" um papel (anon ou authenticated) ou como um usuário específico (recurso de User Impersonation). Escolha a Ana e confira se ela vê só os dados dela. Depois teste como anon, sem login, e veja se as tabelas privadas voltam vazias.
3. Cuidado com o SQL Editor no modo padrão. Sem escolher um papel, ele roda com permissão de administrador e ignora o RLS. Um teste ali "dando certo" não prova nada.
4. Peça correções pontuais à IA. Ao pedir ajuda ao Lovable, descreva a regra de negócio ("cada usuário só vê os próprios pedidos") em vez de "faça o app voltar a funcionar". A segunda frase costuma terminar em using (true) ou em RLS desligado.

Quer uma segunda opinião?

O RLS é só uma das portas de entrada de um app. Para revisar as outras antes de abrir o app ao público, use o checklist de segurança para lançar um app feito com IA.

Se você quer saber, por escrito, como está a segurança do seu app, a Prisma Digital faz um diagnóstico de segurança para apps feitos com IA: revisamos banco, chaves, login e integrações, e você recebe um relatório com os riscos em ordem de prioridade e o passo a passo da correção.