Como as falhas no Supabase derrubaram um site de golpes?

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, o que facilitou a análise com o Burp Suite, 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 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.

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 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. 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 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