Supabase: 16 mil bancos expostos, e a trava de outubro não os fecha

O diretor de segurança da Supabase, Bil Harmer, disse ao TechCrunch nesta sexta, 25 de setembro de 2026, que os projetos da plataforma são "secure by default" e que "customers control how their own projects are configured". Ele respondia a um estudo da UpGuard, publicado no mesmo dia, que encontrou 16.326 bancos hospedados na Supabase com tabelas que qualquer pessoa na internet consegue ler.

As duas frases do executivo convivem com uma terceira, da própria Supabase, escrita em abril. É a nota que anuncia a mudança de exposição das tabelas, e ela diz, sobre o dia em que a mudança chega a todos os projetos: "Existing tables are not affected in your project, they keep their current grants and stay reachable."

Traduzindo: a trava vem, mas para as tabelas que você criar depois dela. As que já estão no ar continuam como estão.

O que muda em 30 de outubro, e o que fica como está

O banco da Supabase é um Postgres com uma API pronta na frente. Toda tabela do schema public pode ser lida pelo navegador do usuário, usando a chave publicável, que vai no código do site. O que impede qualquer um de ler tudo são duas camadas: a permissão de acesso à tabela (o grant) e a regra de linha (Row Level Security, o RLS), que diz quem vê qual registro.

A documentação da Supabase é direta sobre o que acontece quando a segunda camada falta: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it". Legível e gravável.

A mudança anunciada em 28 de abril mexe na primeira camada. A partir de 30 de maio, isso começou a virar o padrão dos projetos novos; em 30 de outubro, a regra passa a valer para todos os projetos existentes, e a partir dali cada tabela nova precisa de um grant explícito para aparecer na API. A nota diz também que o comportamento do RLS não muda.

Faltam 35 dias para essa data. Ela resolve o próximo erro, o da tabela criada em novembro. Não resolve o que já está exposto hoje, e a nota não deixa dúvida sobre isso.

Como a UpGuard chegou a 16.326 bancos, e o que a conta não prova

O estudo, assinado por Greg Pollock, diretor de pesquisa da UpGuard, partiu de cerca de 300 mil domínios com sinais de uso da Supabase, levantados no BuiltWith e no Chrome UX Report. Para cada um, os pesquisadores pediram ao banco uma tabela chamada users e registraram a resposta: nada acessível, outra tabela acessível, ou uma página de registros. Chegaram a 16.326 bancos com tabela legível, e mais da metade deles com sinais de dado pessoal.

Pela nossa conta, é um banco exposto para cada 18 domínios da amostra, perto de 5%. A base é aproximada, e o estudo mistura domínio com banco, então o número serve como ordem de grandeza, não como taxa.

O que aparece nos casos que a UpGuard detalhou vai de nome, e-mail e endereço a placa de carro, histórico de visitas, mensagens privadas e códigos de SMS. Senha em texto puro e token de autenticação aparecem em parcela menor. O estudo diz que B2B ou B2C não fez diferença no tipo de dado exposto, e que comércio eletrônico e restaurantes concentram mais dado pessoal e de pagamento.

O que a conta não prova também precisa ficar dito. Tabela legível não é vazamento confirmado: ninguém sabe, pelo estudo, se alguém além dos pesquisadores leu aqueles dados. A UpGuard analisou esquemas, não cada linha. O estudo não separa por ferramenta de criação, não traz recorte por país e não cita o Brasil. E diz que avisou os donos das aplicações nos casos de exposição significativa, sem publicar quando.

Por que o app feito por agente cai nesse buraco

A explicação da UpGuard para o padrão é uma frase: "Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default." A documentação da Supabase confirma a diferença: tabela criada pelo painel nasce com RLS ligado, e tabela criada por SQL ou por outra ferramenta precisa que alguém o ligue. Quem pede a um agente de código que monte o backend recebe tabelas criadas por comando, e aí o RLS depende de o agente lembrar.

Os outros dois padrões do estudo completam o quadro: regra de acesso que existe mas libera tudo, e chave pública usada como se fosse segredo. A chave publicável foi feita para ir ao navegador. Ela só é segura quando as tabelas por trás dela têm regra.

O ponto do estudo que mais serve ao decisor é o de quem sabe o quê: segundo a UpGuard, o traço comum é que o site foi montado por agente de código e a pessoa não conhece a configuração. O app funciona na demonstração, porque ler tudo também é funcionar.

É o que vemos nos pedidos que chegam à X-Apps: MVP montado em Lovable com Supabase, CRM em React com Supabase, com o pedido de "revisar a arquitetura" antes de crescer. A regra de acesso a dados é uma das primeiras coisas que conferimos nessa revisão, porque é a falha que o app em funcionamento não denuncia.

Quando a tabela aberta vira assunto de LGPD

Para a empresa brasileira, a pergunta deixa de ser técnica quando a tabela aberta tem dado de cliente. Acesso não autorizado a dado pessoal é incidente de segurança, e a Resolução CD/ANPD nº 15/2024 dá ao controlador 3 dias úteis, contados de quando ele toma conhecimento, para comunicar a ANPD e os titulares quando o incidente pode trazer risco ou dano relevante. O que pesa nessa avaliação é a natureza dos dados, o número de pessoas e o que foi feito para conter.

Nem toda tabela exposta vira comunicação obrigatória. Uma lista de produtos aberta não entra nessa conta; um cadastro com CPF e telefone é o caso típico que entra. O que o estudo muda é o "tomar conhecimento": no dia em que a empresa roda a conferência e acha uma tabela de cadastro aberta, ela passa a ter de avaliar se houve acesso e qual o risco, e, se houver incidente com risco relevante, é desse conhecimento que os 3 dias úteis contam. Convém descobrir com alguém que já sabe o que fazer no dia seguinte.

Quem pode ler o estudo e seguir em frente

Quem criou as tabelas pelo painel da Supabase, com RLS ligado e regra escrita tabela a tabela, está no caso que a própria documentação descreve como protegido, e o estudo não traz nada novo para ele. O mesmo vale para quem já roda as duas consultas do fim deste texto como parte do processo de publicação.

E vale separar o problema da plataforma. Em agosto, recomendamos a Supabase numa pilha para MVP, e o argumento mais forte foi justamente o RLS: regra de acesso que é do banco, não do fornecedor, e que sai junto num dump. O estudo não muda essa leitura. Ele mostra que a regra só protege quando alguém a escreve, e que agente de código, sem instrução, nem sempre escreve.

A resposta do executivo da Supabase também não resolve a questão, nem para um lado nem para o outro. Ela descreve a divisão de responsabilidade, e a divisão é real: a configuração do projeto é do cliente. É exatamente por isso que a conferência também é.

A conferência que cabe numa tarde

Duas consultas, rodadas no editor SQL do projeto, mostram o que importa. A primeira lista as tabelas do public, diz se o RLS está ligado e se a chave pública consegue ler:

select c.relname as tabela,
       c.relrowsecurity as rls_ligado,
       has_table_privilege('anon', c.oid, 'select') as chave_publica_le
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r'
order by rls_ligado, tabela;

Linha com rls_ligado falso e chave_publica_le verdadeiro é tabela aberta para qualquer visitante. A segunda procura o caso mais sutil, a regra que existe e libera tudo:

select tablename, policyname, roles, cmd
from pg_policies
where schemaname = 'public' and qual = 'true';

Regra com true pode ser intencional, num catálogo público por exemplo. Em tabela de cadastro, pedido ou mensagem, não é.

Se o app foi montado por agente, peça essas duas saídas a quem cuida dele ainda nesta semana, antes de 30 de outubro, porque a data não vai mudar nada nas tabelas que aparecerem ali. Quantas linhas da primeira consulta voltam com rls_ligado falso no seu projeto?

Os números e de onde vêm

• 16.326 bancos com tabela legível, cerca de 300 mil domínios na amostra, mais da metade com sinais de dado pessoal: estudo da UpGuard, Greg Pollock, 25/09/2026. Classe: fonte primária do pesquisador. O "1 em cada 18" e o "perto de 5%" são nossa conta (300.000 ÷ 16.326 e 16.326 ÷ 300.000), sobre uma base aproximada.
• Frase sobre RLS em tabelas criadas pela API: mesmo estudo. Leitura do pesquisador, coerente com a documentação de Row Level Security da Supabase, consultada em 25/09/2026.
• Datas de 28/04, 30/05 e 30/10/2026 e a frase sobre tabelas existentes: nota da Supabase "Breaking change: tables not exposed to Data and GraphQL API automatically", publicada em 28/04/2026. Os 35 dias até 30/10 são nossa conta.
• Declarações de Bil Harmer: TechCrunch, Zack Whittaker, 25/09/2026. Classe: resposta da empresa citada.
• Prazo de 3 dias úteis: Resolução CD/ANPD nº 15/2024, arts. 6º e 9º, página oficial da ANPD sobre comunicação de incidente, consultada em 25/09/2026.