16 mil bancos de dados expostos no Supabase: o problema não é a IA escrever o código

Alguém na sua empresa subiu um aplicativo essa semana. Um formulário de captação, um painel de indicadores, um controle de agendamento que a equipe montou em dois dias porque o caminho oficial levaria três meses.

Agora a pergunta difícil: quem revisou?

Em 25 de setembro, a empresa de segurança UpGuard publicou uma pesquisa que dá peso concreto a essa pergunta. Assinada por Greg Pollock, Director of Research and Insights da companhia, ela partiu de cerca de 300 mil domínios únicos onde havia indicadores de uso do Supabase — identificados combinando o fingerprint tecnográfico da BuiltWith com o dataset do Chrome UX Report no BigQuery. Cada domínio foi consultado procurando uma tabela chamada "users". Alguns negaram acesso. Outros devolveram pistas de tabelas vizinhas. E 16.326 devolveram tabelas legíveis para qualquer pessoa na web aberta.

Mais da metade desses bancos apresentava indicadores de dado pessoal. Um percentual menor trazia senhas ou tokens de autenticação. Um número muito pequeno continha dados plausíveis de cartão de crédito — mais comum era encontrar evidência de integração com sistema de pagamento.

Os casos documentados no relatório saem do abstrato rápido. Um serviço de valet nos Estados Unidos com mais de 100 mil clientes cadastrados: nome, telefone, placa do carro e histórico de visitas, além de 665 registros de funcionários. Um serviço de imigração canadense com quase 5 mil registros contendo nome completo, e-mail, telefone e data de nascimento — 884 deles com a senha em texto puro. O consulado de um governo africano na França, com 25 mil usuários, dado pessoal e endereço físico, incluindo local de moradia de emergência. Um serviço de verificação por SMS nas Filipinas com mais de 100 mil mensagens contendo códigos de autenticação.

Nenhum desses bancos foi invadido. Eles estavam abertos.

Um default que muda de lugar

O Supabase oferece Postgres gerenciado. O acesso ao banco acontece por uma API HTTP, usando uma chave pública que fica no código do front-end. Isso não é falha, é o desenho do produto — é o que permite subir um app sem manter servidor próprio.

A proteção que decide quem pode ler qual linha é o Row Level Security, o RLS. Segundo a documentação da Supabase, uma tabela em schema exposto sem RLS habilitado é legível e gravável por qualquer role que tenha grant sobre ela — e tabelas novas recebem grant para o role anônimo por padrão. Traduzindo para consequência prática: sem RLS, a chave pública que está no JavaScript da sua página é suficiente para ler a tabela inteira.

E aqui está o detalhe que explica a escala. Segundo a pesquisa da UpGuard, a Supabase passou a habilitar RLS por padrão nas tabelas criadas pela interface do Table Editor a partir de março de 2025. Tabelas criadas programaticamente, pela API — que é exatamente como agentes de código interagem com o banco —, não recebem a proteção por padrão.

O caminho mais rápido é o menos protegido.

A pesquisa nomeia as ferramentas que operam por esse caminho: Claude Code, Codex da OpenAI, Lovable e Replit. Não porque tenham um defeito exclusivo, mas porque todas escrevem schema por API, e não por interface.

Procurada pelo TechCrunch, a Supabase respondeu pelo seu CISO, Bil Harmer, afirmando que os projetos são seguros por padrão e que segurança é uma responsabilidade compartilhada entre a empresa e seus clientes: a plataforma oferece defaults seguros e ferramentas, e o cliente controla como configura o próprio projeto.

As duas afirmações podem ser verdadeiras ao mesmo tempo. É exatamente aí que mora o problema de gestão.

O que realmente falhou

A leitura fácil dessa notícia é que a inteligência artificial escreve código insegura. É confortável e, na melhor das hipóteses, incompleta.

O código gerado fez o que foi pedido: criou a tabela, conectou a interface, entregou o aplicativo funcionando. Ele não falhou tecnicamente. Ele deixou de fazer algo que nunca foi pedido — porque ninguém no caminho tinha a atribuição de pedir.

Vale olhar o que mudou de estrutura, não de ferramenta. Até pouco tempo, a distância entre "tive uma ideia de aplicativo" e "esse aplicativo está no ar com dado de cliente dentro" era medida em semanas e passava obrigatoriamente por um desenvolvedor, por alguém de infraestrutura, por uma credencial que outra pessoa precisava liberar. Cada uma dessas passagens era, sem que ninguém a chamasse assim, um ponto de revisão.

Hoje essa distância é uma tarde de trabalho.

A leitura mais plausível do que a pesquisa expõe é essa: os pontos de revisão que existiam por atrito, e não por desenho, desapareceram junto com o atrito. A conclusão do próprio relatório aponta na mesma direção ao afirmar que vazamentos de dados são o produto multiplicativo entre a facilidade de configurar algo errado e o tamanho da base de usuários — a UpGuard compara o caso com as correções de padrão que S3 e GitHub tiveram que fazer no passado, depois de erros repetidos em escala.

Para quem dirige uma empresa, a consequência é mais direta. Shadow IT — a tecnologia que a operação adota sem passar pela área responsável — deixou de ser uma planilha paralela e passou a ser um aplicativo em produção com banco de dados próprio.

A diferença de risco entre as duas coisas é grande. Uma planilha paralela cria inconsistência de informação. Um aplicativo em produção com banco aberto cria exposição de dado de terceiro, com desdobramento regulatório, contratual e de reputação que não fica dentro da equipe que subiu o app.

Cinco perguntas antes de um app interno tocar dado de cliente

Proibir a equipe de construir não resolve. Empresa que proíbe passa a construir escondido, e o resultado é pior: o app continua existindo, só não aparece em lugar nenhum. O que dá para fazer é recolocar, por desenho, o ponto de revisão que o atrito fazia de graça.

Cinco perguntas cobrem a maior parte do risco descrito na pesquisa. Nenhuma delas exige um time de segurança dedicado.

1. Qual dado real está dentro?

Não o que o app se propõe a fazer, e sim o que a tabela guarda hoje. Dado pessoal identificável, documento, telefone, histórico de compra e credencial mudam completamente o nível de cuidado exigido. Boa parte dos casos do relatório é exatamente isso: um aplicativo simples guardando muito mais informação sensível do que sua aparência sugere. Se o app não precisa do campo, o caminho mais seguro é não coletar.

2. O RLS está habilitado e existe política escrita?

São duas verificações, não uma. Habilitar RLS sem criar nenhuma política bloqueia o acesso — esse é o comportamento seguro. O caso perigoso é o inverso: a tabela no ar sem RLS habilitado, aberta a quem tiver a chave pública. A checagem tem que ser feita tabela por tabela, em todo schema exposto, e refeita a cada nova tabela criada depois da primeira revisão.

3. Qual chave está no código que roda no navegador?

A documentação de chaves de API da Supabase é explícita nesse ponto: a chave publicável pode ir para páginas web e aplicativos entregues ao usuário, mas a chave secreta ignora todas as políticas de RLS e não deve ser colocada em navegador, em aplicativo distribuído ou em controle de versão. Uma chave secreta vazada torna irrelevante qualquer política configurada.

4. Quem é o dono do projeto e quem tem acesso?

Muitos desses aplicativos nascem na conta pessoal de quem os construiu. Vale responder antes: onde o projeto está hospedado, sob qual conta, quem consegue entrar no painel, e o que acontece com esse acesso no dia em que a pessoa sair da empresa. Aplicativo sem dono registrado é aplicativo sem manutenção de segurança.

5. Quem assina a liberação?

Essa é a pergunta que devolve o ponto de revisão. Não precisa ser um comitê. Precisa ser um nome — alguém com a atribuição de olhar as quatro perguntas anteriores e dizer se o app pode ou não tocar dado de cliente. Sem esse nome, a decisão continua sendo tomada, só de forma distribuída e sem registro.

O que a pesquisa não diz

Duas ressalvas importam para não esticar a conclusão além da evidência.

A UpGuard mediu exposição, não origem. O estudo identifica bancos Supabase com tabelas legíveis e explica por que o caminho programático de criação favorece esse erro, mas não confirma, caso a caso, que cada um dos 16.326 bancos tenha sido produzido por uma ferramenta de IA. Parte deles pode vir de desenvolvimento manual, de ambiente de teste que virou produção ou de projeto abandonado.

Também não é possível afirmar, com o que está público, quantos desses bancos foram efetivamente acessados por terceiros antes da pesquisa. Exposição disponível e vazamento consumado são coisas diferentes, e o relatório não faz essa medição.

O que o estudo sustenta com segurança é mais modesto e ainda assim suficiente para mudar decisão: existe um volume grande de bancos abertos, mais da metade com indicador de dado pessoal, em um serviço que se tornou escolha quase padrão de aplicações construídas rápido.

O custo de construir caiu; o de errar não

A tecnologia que reduz o custo de construir não reduz o custo de errar. Ela entrega o erro mais rápido, em mais lugares, e com menos gente olhando no caminho.

Quando a barreira técnica cai, governança para de ser um assunto de infraestrutura e passa a ser uma decisão de gestão. Alguém precisa ter o nome escrito ao lado da pergunta "esse aplicativo pode tocar dado de cliente?".

Se ninguém tem, a resposta já está sendo dada. Só não por escolha.