# Como as falhas no Supabase derrubaram um site de golpes?

> Published 2026-09-27T14:41:24.614Z on https://www.crazystack.com.br/pt/p/como-as-falhas-no-supabase-derrubaram-um-site-de-golpes/
> Source video: https://www.youtube.com/watch?v=POl5KwUEgRM

As falhas no Supabase foram o ponto de partida de um investigador que derrubou um site de cartões clonados no Brasil. Ele explorou tabelas expostas, sessões manipuláveis e ausência de rate limit. O caso, narrado em vídeo em 2026, serve de alerta para qualquer app gerado por IA sem configuração de segurança.

## O que aconteceu no caso do site de cartões clonados

Um investigador que publica como Yuri Dev invadiu uma loja ilegal de cartões clonados e o canal O Rei dos Sites reageu ao caso em julho de 2026. Segundo o vídeo, o site era um fornecedor que atendia mais de 15 lojas menores. A porta de entrada foram falhas no Supabase backend Postgres que servia todas as requisições da aplicação.

Todo o tráfego do site apontava para chamadas do [Supabase](https://supabase.com), o que facilitou a análise com o [Burp Suite](https://portswigger.net/burp), ferramenta que intercepta requisições do navegador. O investigador relata que a maioria das chamadas usava RPC, então ele seguiu pelo front-end: o site era React e expunha os nomes das tabelas no código do cliente.

Importante manter o escopo: as afirmações vêm do vídeo e da experiência relatada pelo investigador. Não há auditoria independente publicada. O que resta é a lição técnica, que qualquer desenvolvedor consegue reproduzir em estrutura de projeto semelhante.

## Por que falhas no Supabase aparecem em apps gerados por IA

Falhas no Supabase quase nunca são culpa do banco em si. O Supabase um Postgres gerenciado com autenticação, storage e edge functions, e a segurança depende de Row Level Security (RLS), o recurso do Postgres que restringe linhas por usuário. Quando um construtor como o [Lovable](https://lovable.dev) gera o app por prompt, quem responde pelas políticas de acesso é a configuração entregue, não a ferramenta.

O vídeo mostra três erros clássicos de projeto mal configurado. Primeiro, tabelas como resellers respondiam 200 com dados para o token anônimo. Segundo, endpoints de sessão aceitavam um user ID e devolviam a sessão correspondente, sem verificar quem pedia. Terceiro, não havia rate limit nas rotas administrativas.

O apresentador também cita uma mudança recente: segundo ele, o endpoint rest/v1 parou de listar todas as tabelas por padrão desde abril de 2026. Trate isso como relato do vídeo e confirme o comportamento atual na [documentação do Supabase](https://supabase.com/docs).

## Como a invasão aconteceu, passo a passo

A sequência do vídeo segue uma lógica de engenharia reversa comum em APIs expostas. Cada etapa usa apenas requisições manipuladas no cliente. O resumo em ordem:

1. Mapear as chamadas com o Burp Suite e notar que tudo aponta para o Supabase.
2. Chutar nomes de tabelas e depois extrair os nomes reais do bundle React, procurando pela função from.
3. Ler dados da tabela resellers, incluindo o campo owner user ID, que liga a loja a uma conta.
4. Descobrir que nenhuma sessão fica salva no [localStorage](https://developer.mozilla.org/pt-BR/docs/Web/API/Window/localStorage) nem em cookies: a autenticação não prova identidade.
5. Forjar a resposta do endpoint authenticate user, trocando o user ID, e entrar na conta de terceiros sem senha.
6. Desativar o 2FA forjando a resposta de tfa enabled como falsa e cadastrando um novo secret.

O 2FA foi o último obstáculo, e ainda assim cedeu. A validação do código tinha limite de tentativas no servidor, o que ajudou. O problema ficou no cadastro do próprio 2FA: ao forjar a resposta que dizia que o fator estava desativado, o sistema aceitou sobrescrever o secret antigo. Segundo o investigador, isso devolveu o controle total do painel admin, com histórico de atividades, estoque e dados dos compradores.

Depois disso, o vídeo relata ações para atrapalhar a operação: exclusão dos cartões à venda e sobrescrita dos dados dos revendedores. A função RPC de deletar usuários, curiosamente, não fazia nada, sinal de código gerado sem testes.

## A alegação de brute force na Magazine Luiza

A parte mais sensível do vídeo é a alegação sobre a [Magazine Luiza](https://www.magazineluiza.com.br). O investigador conta que, com o número do pedido em mãos, a página pública de rastreio pedia os quatro primeiros dígitos do CPF. Como são 10.000 combinações, ele afirma ter testado todas com o Intruder do Burp e recebido os dados de entrega. Trate isso como acusação de terceiros: nenhuma fonte oficial da empresa confirmou a falha ou anunciou correção até a data deste artigo.

Mesmo sem confirmação, o padrão é conhecido. Endpoint público de consulta + segredo de baixa entropia + ausência de rate limit equivale a porta aberta. Se você mantém qualquer rastreio ou consulta por documento, exija um token forte por pedido, limite tentativas por IP e monitore picos de requisição. Empresas costumam ter programas de recompensa para relatos responsáveis; testar em produção sem autorização pode configurar crime informático no Brasil, conforme o Código Penal e a Lei 12.737/2012.

## Checklist para proteger seu app Lovable + Supabase

As falhas no Supabase caso se resolvem com configuração documentada. Use a [documentação de RLS do Supabase](https://supabase.com/docs/guides/database/postgres/row-level-security) e revise estes pontos antes do deploy:

- **RLS em todas as tabelas**: habilite policies por tabela e teste com o token anônimo, não só logado.
- **Sessão verificada no servidor**: nunca confie em user ID vindo do cliente; derive a identidade do JWT.
- **2FA no backend completo**: a checagem do fator e a troca de secret precisam validar o estado atual no servidor.
- **Rate limit e monitoramento**: limite tentativas em rotas de login, verificação e consulta pública.
- **Segredo de alta entropia**: nada de 4 dígitos de CPF como única barreira de acesso a dados.
- **Front-end sem segredos**: qualquer coisa no bundle React é pública; mantenha lógica sensível no servidor.

O apresentador sugere usar Next.js para esconder chamadas no server side. A mudança ajuda, mas não substitui as policies: se a policy do Postgres está errada, o dado continua legível por qualquer cliente com a URL do projeto.

## Lovable, Supabase Next.js: quem responde pelo quê

Muita gente culpa a ferramenta errada depois de um caso assim. Cada camada da stack tem uma responsabilidade diferente, e a falha mora onde a responsabilidade foi ignorada.

| Camada | Papel | Risco se mal configurada |
| --- | --- | --- |
| Lovable | Gera o app e faz o deploy por prompt | Código sem policies nem validação de servidor |
| Supabase | Postgres, auth, storage e RPC | Tabelas legíveis por token anônimo sem RLS |
| Next.js | Camada server side opcional | Exposição de chamadas quando tudo roda no cliente |
| 2FA próprio do app | Segundo fator do negócio | Sobrescrita de secret se o servidor aceita resposta forjada |

A conclusão prática: ferramenta nenhuma garante segurança sozinha. O app do caso juntou geração por IA, banco sem policies e validações no cliente, e cada escolha ampliou a anterior.

## FAQ

- **O Supabase inseguro por padrão?** Não. As falhas no Supabase descritas no vídeo vêm de configuração: RLS desativada ou mal escrita e endpoints de negócio sem verificação no servidor. Com as policies corretas, o produto é usado em produção por muitos times.

- **Usar Lovable torna meu app mais vulnerável?** O Lovable acelera a entrega, e o risco aparece quando você publica sem revisar as policies do banco e a autenticação. Revise o que foi gerado antes do deploy, especialmente regras de acesso a tabelas.

- **A Magazine Luiza confirmou a falha de brute force?** Até a data deste artigo, não há confirmação oficial. A alegação vem do vídeo publicado em 2026 e deve ser lida como relato de terceiros, não como fato confirmado.

- **O 2FA falhou no caso? O que aprender com isso?** O código em si resistiu, com limite de tentativas no servidor. O que cedeu foi o cadastro do fator: o app aceitou sobrescrever o 2FA existente com base em resposta forjada no cliente. Valide sempre o estado real no backend.

- **Posso testar falhas em sites de terceiros para aprender?** Não sem autorização. Explorar sistemas alheios sem permissão é crime no Brasil, mesmo com boa intenção. Pratique em laboratório próprio, com apps seus ou plataformas de desafios legais.

[Source video](https://www.youtube.com/watch?v=POl5KwUEgRM)