Eu estava trabalhando normalmente em um dos meus projetos no Supabase quando uma notícia publicada pelo TechCrunch chamou minha atenção: uma pesquisa da empresa de segurança UpGuard encontrou milhares de bancos de dados hospedados na plataforma com informações acessíveis publicamente na internet.
Como uso ferramentas modernas para desenvolvimento, esse tipo de notícia merece uma pausa. Afinal, o problema não envolve apenas grandes empresas ou sistemas complexos.
Um projeto criado rapidamente, inclusive com ajuda de inteligência artificial, pode acabar carregando uma configuração de segurança inadequada sem que o desenvolvedor perceba.
A questão que me veio imediatamente foi simples: será que meu próprio projeto está realmente protegido?
E essa é justamente a pergunta que qualquer pessoa que utiliza Supabase deveria fazer agora.
Neste artigo, vou explicar o que foi descoberto, quais tipos de dados podem ficar expostos e, principalmente, quais configurações você deve verificar para reduzir o risco de deixar seu banco de dados acessível para qualquer pessoa.
O que aconteceu com os projetos do Supabase?
Uma investigação da UpGuard identificou milhares de bancos de dados hospedados no Supabase que apresentavam algum tipo de exposição pública. A descoberta foi divulgada pelo TechCrunch em 25 de setembro de 2026.
É importante fazer uma distinção: isso não significa que o Supabase tenha sido hackeado ou que todos esses projetos tenham sofrido uma invasão.
O problema apontado está relacionado principalmente à forma como determinados projetos foram configurados pelos próprios usuários.
Em outras palavras, o banco de dados pode estar funcionando normalmente, mas permissões, políticas de acesso ou configurações da API podem permitir que informações sejam consultadas por pessoas que não deveriam ter acesso.
Esse tipo de situação é conhecido como misconfiguração de segurança.
E justamente por ser uma falha de configuração, ela pode passar despercebida durante bastante tempo.
Quantos bancos de dados foram encontrados?
Segundo a pesquisa citada pelo TechCrunch, a UpGuard encontrou aproximadamente 16 mil bancos de dados do Supabase com algum nível de exposição.
Esse número chama atenção principalmente porque demonstra como um erro aparentemente pequeno pode se repetir em milhares de projetos.
A exposição também não significa que todos os bancos continham informações extremamente sensíveis ou que todos foram efetivamente explorados por criminosos.
O ponto principal é outro: dados que deveriam exigir algum tipo de autorização estavam potencialmente acessíveis pela internet.
Para quem desenvolve aplicações, isso é um alerta importante.
Um banco de dados pode estar hospedado em uma plataforma com diversos mecanismos de segurança e, ainda assim, uma configuração inadequada no nível da aplicação abrir uma porta desnecessária.
Que tipos de informações podem ficar expostos?
A investigação identificou diferentes categorias de informações disponíveis publicamente.
Entre os dados encontrados estavam:
- nomes;
- números de telefone;
- endereços;
- informações de clientes;
- conversas privadas;
- placas de veículos;
- credenciais;
- tokens de autenticação;
- outros dados armazenados pelas aplicações.
O TechCrunch também relatou exemplos envolvendo um serviço adulto, uma empresa de valet, uma companhia de imigração e realocação e outros projetos.
Isso mostra por que uma simples configuração de banco de dados pode se transformar em um problema muito maior.
Uma informação isolada pode parecer pouco importante. Porém, quando nome, telefone, endereço e outros dados são combinados, o conjunto pode ser usado em tentativas de phishing, engenharia social e diferentes tipos de fraude.
O problema está no Supabase ou na configuração do projeto?
Essa é uma das partes mais importantes para entender o caso. O Supabase trabalha com um modelo de responsabilidade compartilhada.
A empresa é responsável pela infraestrutura da plataforma e por diversos controles de segurança, enquanto o cliente continua responsável por aspectos como dados, gerenciamento de acesso, arquitetura da aplicação, banco de dados e aplicação das políticas de segurança.
A própria documentação do Supabase deixa claro que o usuário é responsável pelo controle de acesso ao banco, pelas tabelas com informações sensíveis, pelas chaves e pelos controles de segurança aplicados ao projeto.
A plataforma recomenda o uso de Row Level Security (RLS) para restringir o acesso aos dados.
Portanto, não é correto interpretar a pesquisa simplesmente como “o Supabase vazou 16 mil bancos”.
O cenário descrito é mais específico: projetos de clientes foram encontrados com configurações que permitiam exposição de dados.
Por que a inteligência artificial pode aumentar esse risco?
Aqui existe uma questão especialmente interessante para quem cria sites e aplicativos atualmente.
Ferramentas de inteligência artificial conseguem gerar uma aplicação funcional em poucos minutos.
Plataformas de desenvolvimento assistido por IA e soluções low-code também reduziram bastante a barreira técnica para colocar um produto no ar.
Isso é excelente para prototipação.
Mas existe uma armadilha.
Código que funciona não é necessariamente código seguro.
Uma IA pode criar uma tabela, configurar uma API, gerar consultas ao banco e montar uma tela de login. Tudo pode funcionar perfeitamente no navegador.
O problema aparece quando alguém pergunta:
Quem exatamente pode acessar esses dados?
Essa pergunta precisa ser respondida por regras de autenticação e autorização, não apenas pela interface da aplicação.
Por isso, quem utiliza IA para criar aplicações precisa revisar especialmente:
- políticas RLS;
- permissões das tabelas;
- chaves de API;
- variáveis de ambiente;
- funções do banco;
- endpoints;
- autenticação;
- permissões de usuários;
- dados armazenados em tabelas públicas.
A documentação do Supabase recomenda explicitamente o uso de RLS nas tabelas e views expostas pela Data API.
Como saber se seu projeto Supabase está exposto?
Se você possui um projeto no Supabase, vale fazer uma revisão de segurança agora, principalmente se ele foi criado rapidamente ou recebeu código gerado por IA.
1. Verifique as tabelas do banco
Comece identificando quais tabelas contêm informações privadas.
Pergunte:
Essa tabela realmente precisa estar acessível pela API?
Se a resposta for não, revise os privilégios e a exposição da tabela.
A documentação atual do Supabase explica que objetos expostos pela Data API precisam ter controles adequados de acesso.
2. Confira o Row Level Security
O Row Level Security, conhecido como RLS, permite determinar quais registros cada usuário pode visualizar ou modificar.
Imagine uma aplicação em que cada usuário possui seus próprios pedidos.
Não basta verificar se a pessoa está autenticada.
A aplicação também precisa garantir que:
João consiga acessar os pedidos de João, mas não os pedidos de Maria.
É exatamente esse tipo de controle que o RLS ajuda a implementar.
O Supabase recomenda habilitar RLS nas tabelas e views expostas pela Data API e criar políticas que definam quais usuários podem acessar determinados registros.
3. Procure por chaves expostas
Outro ponto importante são as chaves utilizadas pela aplicação.
Nunca coloque uma chave secreta diretamente no código do frontend ou em um repositório público.
Também vale verificar:
- arquivos
.env; - repositórios do GitHub;
- scripts;
- logs;
- configurações de deploy;
- ferramentas de IA usadas durante o desenvolvimento.
O Supabase passou a adotar um modelo mais recente de chaves, com chaves publicáveis e secretas que podem ser rotacionadas e ter controles mais granulares.
A empresa também informa que chaves secretas detectadas em repositórios públicos do GitHub podem ser automaticamente revogadas.
Se você ainda utiliza chaves antigas, vale conferir a documentação de migração da plataforma.
4. Revise as funções do banco
Funções PostgreSQL também merecem atenção. Uma função pode ter permissões maiores do que o usuário deveria possuir.
A própria documentação do Supabase alerta que funções SECURITY DEFINER precisam ser revisadas cuidadosamente e que o privilégio EXECUTE deve ser concedido apenas aos papéis que realmente precisam utilizá-las.
Esse é um daqueles detalhes que facilmente passam despercebidos quando a aplicação foi construída rapidamente.
O Supabase está adotando medidas de segurança?
Sim.
A documentação atual do Supabase informa que a plataforma possui controles de segurança e conformidade, incluindo SOC 2 Type 2, além de mecanismos de proteção na infraestrutura.
A empresa também vem trabalhando em mudanças para tornar a configuração de novos projetos mais segura.
Em sua retrospectiva de segurança de 2025, o Supabase destacou mudanças como RLS habilitado por padrão para tabelas criadas pelo Dashboard, novos modelos de chaves e opções para desabilitar a Data API.
Isso é importante porque mostra que a segurança da plataforma continua evoluindo.
Mas existe um detalhe que não muda:
nenhuma configuração automática substitui a revisão das permissões da sua própria aplicação.
O que fazer agora se você usa Supabase?
Se você possui um projeto ativo, eu faria esta pequena auditoria:
Checklist rápido de segurança
Banco de dados
- Identifique quais tabelas armazenam dados sensíveis.
- Verifique quais tabelas estão acessíveis pela API.
- Confirme se o RLS está habilitado.
- Revise as políticas de cada tabela.
- Verifique permissões de leitura e escrita.
Chaves
- Procure chaves no código.
- Revise arquivos
.env. - Confira repositórios públicos.
- Rotacione credenciais que possam ter sido expostas.
- Separe chaves públicas de credenciais secretas.
Autenticação
- Revise os métodos de login.
- Confira permissões por usuário.
- Verifique contas administrativas.
- Ative MFA quando disponível e adequado ao seu projeto.
O Supabase oferece controles para MFA e SSO nas organizações, além de outras configurações de segurança.
E se o aplicativo foi criado com IA?
Nesse caso, eu faria uma revisão ainda mais cuidadosa.
Não basta perguntar para a IA:
“Meu aplicativo está seguro?”
Uma pergunta ou prompt melhor seria:
“Analise todas as tabelas, políticas RLS, funções, permissões, chaves e endpoints deste projeto e identifique qualquer caminho que permita que um usuário autenticado ou não autenticado acesse dados pertencentes a outro usuário.”
Depois, revise manualmente as alterações sugeridas.
IA pode ajudar muito na auditoria, mas não deve ser tratada como autoridade final sobre a segurança do sistema.
Uma aplicação pode funcionar perfeitamente durante os testes e ainda apresentar uma falha grave de autorização.
O que esse caso ensina para quem desenvolve na era da IA?
Para mim, essa é a parte mais importante de toda essa história.
Estamos vivendo uma fase em que alguém sem experiência avançada em programação consegue criar um aplicativo completo utilizando IA, templates e plataformas como o Supabase.
Isso democratiza o desenvolvimento.
Mas também muda o tipo de conhecimento que o criador precisa ter.
Você não precisa necessariamente ser especialista em PostgreSQL para começar um projeto.
Porém, precisa entender conceitos básicos como:
- autenticação, autorização, permissões, RLS, secrets e exposição de APIs.
É justamente aí que muitos projetos podem falhar.
A interface pode estar bonita.
O aplicativo pode funcionar.
O login pode estar funcionando.
Mas a pergunta que realmente importa é:
quem consegue acessar os dados por trás desse aplicativo?
Minha opinião
A descoberta divulgada pela UpGuard e pelo TechCrunch é um alerta importante para qualquer pessoa que utiliza Supabase para criar aplicações.
Mas também é importante interpretar o caso corretamente.
Não se trata simplesmente de dizer que todos os projetos do Supabase estão vulneráveis ou que a plataforma inteira sofreu um vazamento.
O que a investigação mostra é como configurações inadequadas podem transformar bancos de dados aparentemente protegidos em fontes públicas de informação.
E esse problema não é exclusivo do Supabase.
Ele pode acontecer em praticamente qualquer infraestrutura moderna quando permissões são configuradas incorretamente.
Se você usa Supabase, aproveite este momento para abrir seu projeto e revisar as configurações:
- Confira o RLS.
- Revise as permissões.
- Proteja suas chaves.
- Verifique a Data API.
- Analise as funções do banco.
- E, principalmente, não confie cegamente no código gerado por inteligência artificial.
Criar um aplicativo ficou muito mais fácil.
Proteger o que existe por trás dele continua sendo responsabilidade de quem o coloca no ar.
Com informações de TechCrunch
