# Seu app feito com IA está vazando dados?

Canonical URL: https://thorfyn.com/pt/notes/meu-app-feito-com-ia-esta-vazando-dados

> Quatro checagens do Supabase antes de lançar um app do Lovable, Bolt ou v0: RLS, a chave service_role, os redirecionamentos de login e o staging.

Resposta curta: se o seu app do Lovable, Bolt ou v0 usa Supabase, faça quatro checagens antes de chegarem usuários de verdade: RLS em toda tabela, a chave service_role fora do navegador, links de login que só voltam para os seus domínios e um projeto de staging separado da produção.

- Fontes públicas, com link
- Escrito por Matheus Pavaneli (https://thorfyn.com/pt/about)
- Publicado em 10 de out. de 2026
- Revisado em 10 de out. de 2026
- 3 min

## Por que apps feitos com IA vazam

Ferramentas como Lovable, Bolt e v0 criam as tabelas do Supabase de que o app precisa, mas as regras que dizem quem pode ler cada linha são um passo à parte. A chave pública que todo navegador recebe consulta o banco direto, então uma tabela sem regra responde a qualquer um que tenha a chave, logado ou não.

### Como o vazamento acontece

O navegador de todo visitante tem a sua chave anon pública. O que ela lê depende só das regras de cada tabela.

- O navegador do visitante: logado como voce@…, com a chave pública anon
- Uma requisição: GET /rest/v1/profiles com essa chave
- tabela profiles: 1.240 linhas

- **RLS desligado** — 1.240 linhas voltam para o navegador, de todo mundo.
- **RLS ligado** — Uma linha volta para o navegador: a sua.

**9,3 / 10** — é a gravidade que o NVD registra para a CVE-2025-48757: falta de RLS em sites gerados pelo Lovable até 15 de abril de 2025, permitindo a qualquer um ler ou escrever nas tabelas. O Lovable contesta e diz que cada cliente responde pelos próprios dados. (fonte: [NVD](https://nvd.nist.gov/vuln/detail/CVE-2025-48757))

## RLS em toda tabela, ligada ao usuário

Uma tabela com RLS desligado, ou com política que libera todo mundo, pode ser lida inteira com a chave pública.

- **Confira você mesmo** — No painel do Supabase, abra Authentication e depois Policies. Toda tabela do schema public precisa mostrar RLS ligado e uma política que compare uma coluna com auth.uid().
- **Corrija** — Ligue o RLS em cada tabela e escreva uma política por ação. Para as linhas do próprio usuário:

```sql
alter table public.profiles enable row level security;
create policy "own profile" on public.profiles
  for select using (auth.uid() = id);
```

## A chave service_role nunca chega ao navegador

A chave service_role passa por cima de toda regra. Se vai no front-end, qualquer um copia do código da página.

- **Confira você mesmo** — Abra o app no ar, veja o código-fonte e procure service_role nos scripts. Toda chave que aparecer precisa ter o papel anon.
- **Corrija** — Deixe a service_role só no código do servidor ou nos segredos das edge functions, gere uma nova no painel e publique de novo.

## Links de login só voltam para os seus domínios

Um curinga na lista de redirecionamento deixa um link de login forjado entregar a sessão para outro site.

- **Confira você mesmo** — Authentication, depois URL Configuration. A lista deve ter o domínio de produção e os domínios exatos de preview que você usa, sem curinga.
- **Corrija** — Troque os curingas por endereços exatos e deixe localhost só no projeto de desenvolvimento.

## Um projeto de staging separado da produção

Testar contra o banco de produção quer dizer que um teste ou um prompt pode mudar dados de clientes reais.

- **Confira você mesmo** — Confira para qual projeto do Supabase os builds de preview apontam. Se for o endereço de produção, os dois dividem os dados.
- **Corrija** — Crie um segundo projeto para staging, copie o schema com as migrações e aponte os previews para ele.

## Perguntas

### A chave anon é segredo?

Não. Ela é pública de propósito e vai em toda página. Quem decide o que o visitante lê são as regras de cada tabela, não a chave.

### O Lovable liga o RLS para mim?

A documentação do Lovable pede para revisar as políticas de cada tabela antes de publicar. Trate o que foi gerado como rascunho e confira tabela por tabela.

### Dá para fazer as checagens sem mexer em código?

Três das quatro ficam no painel do Supabase. A da service_role só precisa do código-fonte da página no navegador.

## Fontes

- [NVD, CVE-2025-48757](https://nvd.nist.gov/vuln/detail/CVE-2025-48757)
- [Supabase, Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [Lovable, Connect to Supabase](https://docs.lovable.dev/integrations/supabase)

## Quando pedir ajuda

Se alguma checagem falhar e o app já tiver usuários, corrija as duas primeiras hoje. A triagem de um dia lê login, dados expostos, segredos e pagamento, e termina num veredito escrito.

- Ver a triagem de um dia: https://thorfyn.com/pt/triage
- Próxima nota: https://thorfyn.com/pt/notes/app-do-lovable-bolt-v0-para-producao
- Dúvidas e pedidos: hello@thorfyn.com
- Voltar para a página inicial: https://thorfyn.com/pt