16.326 bancos de dados abertos, e a correção são duas linhas de SQL

Vale começar desfazendo uma leitura que apareceu bastante nos últimos dias. Isso não é uma vulnerabilidade do Supabase.

A plataforma expõe uma API REST sobre o banco Postgres e entrega, junto com o projeto, uma chave anônima que fica embutida no JavaScript do site. Ela é pública por desenho. Qualquer pessoa que abra o código-fonte da página encontra essa chave, e isso está documentado. O que decide quem lê o quê é a política de segurança por linha, o Row Level Security do Postgres, que precisa ser escrita tabela por tabela.

Quando a política não existe, a chave pública devolve a tabela inteira. O banco está fazendo exatamente o que foi mandado fazer.

Por que o erro se concentra onde o agente escreveu o código

Esse é o ponto da pesquisa que merece o tempo de quem decide.

Desde março de 2025, depois da CVE-2025-48757, o Supabase passou a habilitar a proteção por padrão nas tabelas criadas pelo editor visual. Quem clica para criar uma tabela recebe a proteção ligada.

Tabela criada por API, no entanto, não recebe a proteção por padrão. E criar tabela por API é exatamente como um agente de codificação interage com a plataforma. O caminho que ficou seguro é o do humano clicando; o caminho que ficou aberto é o da automação.

A UpGuard registra que mais de 60% das bases Supabase criadas recentemente envolvem desenvolvimento assistido por IA, e observa que a plataforma se tornou peça central em aplicações montadas com construtores conversacionais. Os pesquisadores foram honestos sobre o limite dessa correlação: não é possível confirmar que todas as bases expostas foram geradas dessa forma. Mas a combinação entre um padrão inseguro no caminho programático e um volume crescente de código escrito por agente explica bem a escala encontrada.

Há uma lição mais geral aqui, e ela não é sobre Supabase. Quando uma plataforma corrige um padrão inseguro apenas na interface visual, ela protege quem já sabia o que estava fazendo e deixa descoberto quem delegou a decisão. O agente não escreve a política que ninguém pediu.

O que estava legível

A UpGuard consultou o esquema das tabelas em vez de ler linha a linha, dada a escala. Os exemplos nomeados no relatório dão a dimensão do que ficou aberto.

Aplicação	O que estava legível
Serviço de manobrista no nordeste dos Estados Unidos	Mais de 100 mil clientes com telefone, cerca de 43 mil com nome e e-mail e cerca de 78 mil placas de veículo, além do histórico de visitas.
Serviço de mensagens com senha de uso único nas Filipinas	Mais de 2 mil cadastros e mais de 100 mil mensagens SMS contendo os próprios códigos de verificação.
Consultoria de mudança no Canadá	Quase 5 mil registros, dos quais 884 com senha em texto claro.
Consulado de país africano	25 mil cadastros com endereço residencial e local de acolhimento em emergência.
Plataforma de criadores na Índia	Mais de 100 mil mensagens privadas e dado de pagamento.

O caso das senhas de uso único é o mais instrutivo. Uma base que armazena o código enviado por SMS e o devolve a qualquer requisição transforma o segundo fator em formalidade. Não adianta o aplicativo do banco exigir o código se o serviço que o envia publica o histórico.

O custo de corrigir

A correção é habilitar a segurança por linha na tabela e escrever a política que descreve quem pode ler o quê. São duas instruções de SQL por tabela na forma mais simples, e a documentação do Supabase traz os modelos prontos para os casos mais comuns.

O trabalho real não está na correção. Está em descobrir que a tabela existe.

A aplicação que expôs os dados quase nunca é o sistema principal da empresa. É a página de campanha feita pela agência, o formulário de inscrição do evento, o protótipo que virou produção porque funcionava, a ferramenta interna que alguém montou em uma tarde. Nenhuma delas costuma estar no inventário de ativos do time de segurança, e é justamente por isso que ninguém revisou a política.

Roteiro de noventa dias

Primeiros trinta dias: descobrir

• Levante todas as aplicações web da organização, incluindo as que não estão sob o time de tecnologia. Comece pelos domínios e subdomínios registrados, não pela lista de sistemas.
• Para cada uma, procure no código-fonte público da página por indício de chave e endereço de projeto Supabase, Firebase ou equivalente. O indicador está no JavaScript servido ao navegador.
• Registre quem construiu cada aplicação e com qual ferramenta. A resposta "foi a agência" ou "foi feito com um construtor de IA" é um marcador de prioridade, não um encerramento.

Dias trinta a sessenta: testar

• Com a chave anônima obtida do próprio site, consulte as tabelas principais em ambiente controlado e com autorização formal. Se a consulta devolver dado, a política não existe ou não cobre aquele caminho.
• Verifique especificamente as tabelas de usuário, de mensagem, de pedido e de pagamento. São as que a pesquisa encontrou abertas com mais frequência.
• Documente o resultado por aplicação. O registro do teste é o que sustenta a decisão posterior de notificar ou não.

Dias sessenta a noventa: corrigir e institucionalizar

• Habilite a segurança por linha e escreva a política em toda tabela que responda à chave pública.
• Inclua a verificação no roteiro de publicação. Aplicação nova não entra em produção sem a checagem, independentemente de quem a escreveu.
• Trate criação de tabela por API como caminho que exige revisão explícita. É o caminho do agente, e é o que a plataforma deixou sem proteção padrão.

A leitura de LGPD

Uma base com dado pessoal legível sem autenticação é acesso não autorizado a dado pessoal. Não é uma zona cinzenta.

Três consequências práticas para quem opera no Brasil. A primeira é que o relógio da comunicação começa quando a organização toma conhecimento, o que inclui o resultado do teste descrito acima. Descobrir e não registrar não pausa nada.

A segunda é que a responsabilidade não migra para a agência que construiu a aplicação. O controlador é quem determina a finalidade do tratamento, e é a empresa cujo formulário coletou o dado.

A terceira é sobre senha em texto claro, presente em parte das bases encontradas. Além do acesso indevido, há uma falha de segurança na própria forma de armazenamento, e ela é anterior ao incidente. Em uma eventual fiscalização, essa distinção pesa.

Três evidências que um conselho pode exigir

Leitura LATAMSEC

O que essa pesquisa mede, no fundo, não é a qualidade de um produto. É o que acontece com a segurança quando a velocidade de construção sobe e a revisão não acompanha.

Construir uma aplicação com banco, autenticação e publicação levava semanas e passava por pelo menos uma pessoa que sabia o que era política de acesso. Hoje leva uma tarde e pode não passar por ninguém. O ganho é real. O passivo também, e ele fica no banco, respondendo à internet, até alguém perguntar.

A pergunta que vale para o próximo trimestre não é sobre Supabase. É quantas aplicações a organização colocou no ar nos últimos doze meses sem que o time de segurança soubesse, e quantas delas guardam dado de pessoa real.