Supabase tem 16 mil bancos com dados pessoais expostos, aponta pesquisa

Levantamento da UpGuard achou nomes, endereços, senhas e tokens acessíveis publicamente em milhares de projetos hospedados na plataforma, quase sempre por falha de configuração do próprio desenvolvedor.

A empresa de segurança UpGuard identificou cerca de 16 mil bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → hospedados no Supabase com algum grau de exposição pública de dados pessoais, segundo reportagem da TechCrunch publicada em 25 de setembro de 2026. Entre o que a pesquisa encontrou acessível na internet aberta estão nomes, endereços, telefones, senhas de usuários e, em menor quantidade, tokens de autenticação.

O Supabase é uma plataforma de backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → as a service construída sobre Postgres, muito usada por quem quer subir um banco de dados relacional completo, com API REST e autenticação prontas, sem administrar infraestrutura. A empresa chegou a uma avaliação de US$ 10 bilhões neste ano, impulsionada em boa parte pelo crescimento de apps feitos com vibe coding↳Vibe coding9 conteúdosO Vibe Coding e a Nova Era da Programação: Quando a Ideia Vira CódigoAI · ago 2025Vibe Coding com GitHub CopilotGestão Dev & TI · jul 2025Vibe coding: futuro da programação pode ser mais conversado do que escritoAI · mai 2025Ver tudo em AI → hospedados na plataforma, segundo a TechCrunch.

O que a UpGuard encontrou

Os bancos expostos pertenciam a projetos bem diferentes entre si, o que mostra que o problema não é setorial, é estrutural. A reportagem cita, por exemplo, conversas privadas de um site indiano de streaming adulto com conteúdo de trabalhadoras sexuais, placas de milhares de veículos de um serviço de valet nos Estados Unidos, dados de contato de um serviço de imigração e realocação, e o banco de um consulado de um governo africano na França. Um dos casos mais graves envolvia uma fazenda de chips virtuais (SIM farm) usada para interceptar mensagens de texto com códigos de verificação de uso único, o tipo de infraestrutura tipicamente ligada a golpes e phishing.

Segundo a UpGuard, a maior parte dos dados expostos está associada a projetos nos Estados Unidos, mas a empresa classificou o achado como um problema mundial, e a reportagem destaca que a pesquisa se soma a levantamentos anteriores que já haviam encontrado bancos expostos ligados a startups da Y Combinator e outros aplicativos populares hospedados no Supabase.

Por que isso acontece: a chave pública e o RLS

Nota da redação: a descrição técnica abaixo sobre anon key, RLS e PostgREST reflete o entendimento geral e público sobre como esse tipo de arquitetura costuma funcionar; ela não foi verificada diretamente na documentação oficial do Supabase para esta reportagem e deve ser confirmada por quem for aplicar essas recomendações na prática.

O ponto técnico que ajuda a explicar casos como esse não é, pelo que se entende publicamente, um bug do Supabase, é a forma como esse tipo de plataforma costuma ser desenhado para funcionar. Em arquiteturas como a do Supabase, o SDK usado no frontend costuma embutir uma chave pública (a anon key), que por design vai para o navegador do usuário final e pode aparecer no código-fonte da página.

A segurança de verdade, nesse modelo, tende a ficar por conta do Row Level Security (RLS) do Postgres: políticas que decidem quem pode ler ou escrever em cada linha do banco. Se o desenvolvedor não ativa RLS numa tabela, ou ativa mas escreve uma política permissiva demais, qualquer pessoa que descubra a URL do projeto e a chave anônima pode, em tese, consultar a tabela via API REST gerada automaticamente, sem precisar de senha.

É esse desenho geral, chave pública mais responsabilidade do desenvolvedor de configurar as políticas, que ajuda a explicar por que apps feitos com ferramentas de vibe coding são um ponto sensível: essas ferramentas costumam gerar o schema do banco e a integração com o Supabase automaticamente, mas a IA generativa nem sempre configura RLS de forma correta, e o desenvolvedor que não entende Postgres a fundo pode nunca perceber que deixou a porta aberta.

O que a Supabase responde

Procurado pela TechCrunch, o CISO da Supabase, Bil Harmer, disse que a empresa não teve acesso à pesquisa da UpGuard antes da publicação, mas que os projetos da plataforma são "seguros por padrão". Ele descreveu a segurança como responsabilidade compartilhada: "Fornecemos padrões seguros e ferramentas, e os clientes controlam como seus próprios projetos são configurados", disse Harmer, acrescentando que a empresa notifica clientes afetados quando problemas de segurança são descobertos. "Segurança na Supabase nunca está terminada. Nos importamos profundamente em fazer isso direito, e vamos continuar facilitando para que todo desenvolvedor consiga lançar produtos de forma segura", completou.

Na prática, a resposta sugere que ativar RLS em toda tabela que tenha dados sensíveis é o passo básico de segurança, não um item opcional avançado.

O que isso muda para quem constrói no Supabase

Para quem já roda produção na plataforma ou está avaliando migrar um projeto pra lá, o caso não é motivo pra abandonar o Supabase, mas é motivo pra parar e auditar. Alguns pontos práticos que valem a checagem imediata:

• Confirme se RLS está ativado em cada tabela que armazena dado pessoal, financeiro ou de autenticação.
• Revise as políticas existentes, não só a existência delas: uma política USING (true) equivale a não ter proteção nenhuma.
• Nunca trate a anon key como segredo: ela vai ser lida por qualquer usuário, então toda a lógica de acesso precisa estar no banco (via RLS) ou em funções server-side, nunca confiando em esconder a chave no frontend.
• Em projetos vibe-coded, trate o código gerado por IA como rascunho de segurança, não como produto final: revisar manualmente as políticas de acesso ao banco antes de ir pra produção é o mínimo, especialmente quando quem gerou o app não é quem entende de Postgres.
• Ferramentas de terceiros para auditoria, como scanners que testam se a anon key de um projeto consegue ler tabelas sem autenticação, ajudam a pegar esse tipo de erro antes que alguém de fora encontre.

O caso também é um lembrete de que a facilidade de subir um backend completo em minutos, um dos grandes atrativos do Supabase e de ferramentas parecidas, desloca a complexidade de infraestrutura para a complexidade de configuração de permissões. Quem historicamente cuidava de firewall e rede agora precisa entender políticas de RLS no Postgres, e isso ainda não faz parte do checklist de segurança de boa parte dos times que adotaram a plataforma nos últimos anos.

Fonte: TechCrunch