Exposição de Dados no Supabase Coloca Sob Pressão as Alegações de Segurança de Apps Criados por Vibe Coding
O Supabase está sob escrutínio depois que pesquisadores identificaram 16.326 bancos de dados com tabelas publicamente legíveis, apesar de a plataforma descrever seus projetos como seguros por padrão. As conclusões sobre a exposição de dados no Supabase conectam um problema conhecido de segurança na nuvem a uma fonte mais recente de risco: aplicativos montados rapidamente com ferramentas de programação por IA.
A UpGuard encontrou indícios de informações pessoais em mais da metade dos bancos de dados expostos. Os registros afetados incluíam, segundo relatos, nomes, endereços, números de telefone, datas de nascimento, senhas, tokens de autenticação, mensagens privadas, placas de veículos e informações de imigração.
Não se tratou de uma única violação dos sistemas internos do Supabase. As evidências apontam, em vez disso, para bancos de dados de clientes expostos por controles de acesso ausentes ou inadequados. Essa distinção importa, mas não torna a escala menos preocupante.
O relatório transforma uma falha de configuração técnica em um teste para o modelo de vibe coding. Assistentes de IA podem gerar uma interface funcional e conectá-la a um banco de dados hospedado em poucos minutos. Eles não garantem de forma confiável que cada usuário, tabela, função e operação receba a política de autorização correta.
O Que a Pesquisa sobre Exposição de Dados no Supabase Encontrou
A descoberta central da UpGuard não é um único app excepcionalmente descuidado, mas milhares de projetos desenvolvidos de forma independente repetindo erros de segurança semelhantes.
Para sua investigação de setembro de 2026, a UpGuard reuniu cerca de 300.000 domínios únicos que apresentavam sinais de uso do Supabase. Os pesquisadores utilizaram dados do BuiltWith e do Chrome User Experience Report para identificar os sites relevantes.
Em seguida, testaram se cada projeto expunha uma tabela chamada users. Esse nome comum de tabela deu aos pesquisadores um ponto de partida consistente, sem exigir conhecimento prévio do design de banco de dados de cada aplicativo.
O teste gerou várias respostas possíveis. Um banco de dados seguro ou inativo não retornava dados acessíveis. Alguns bancos revelavam outra tabela acessível por meio de uma sugestão de erro. Outros retornavam uma página de registros.
Nesse conjunto de possíveis alvos, a UpGuard identificou 16.326 bancos de dados com tabelas legíveis. Mais da metade continha campos de esquema que sugeriam alguma forma de informação de identificação pessoal, segundo a pesquisa sobre exposição da empresa.
Os pesquisadores analisaram principalmente esquemas de tabelas, em vez de baixar todos os registros disponíveis. Um esquema revela nomes de colunas e tipos de dados, que podem indicar se uma tabela contém endereços de e-mail, senhas, números de telefone ou informações de pagamento.
Essa abordagem reduziu o acesso desnecessário a registros pessoais. Também significa que o número de 16.326 não estabelece que todos os bancos de dados continham informações sensíveis nem que invasores tenham copiado anteriormente os dados disponíveis.
A UpGuard investigou casos selecionados nos quais os metadados sugeriam uma exposição relevante. Os exemplos mostram como um erro de configuração pode deixar de ser dívida técnica e causar danos pessoais diretos.
Um serviço indiano de streaming adulto expunha uma tabela com dados de 65.467 pessoas. Os campos incluíam, segundo relatos, documentos de identidade, endereços, datas de nascimento, contas financeiras e números parciais de identificação governamental. Outra tabela mantinha mais de 100.000 mensagens privadas envolvendo criadores de conteúdo.
Uma operação de SIM virtual nas Filipinas expunha informações de mais de 2.000 usuários e mais de 100.000 mensagens de texto. A maioria das mensagens continha códigos de uso único, mas a amostra também incluía milhares de comunicações comuns entre motoristas e passageiros de serviços de transporte por aplicativo.
Um serviço de manobrista dos Estados Unidos expunha registros envolvendo mais de 100.000 clientes. Seu banco de dados incluía aproximadamente 78.000 números de placas, cerca de 43.000 endereços de e-mail, históricos de visitas, informações sobre gorjetas e anotações em texto livre.
Os pesquisadores também encontraram um banco de dados de um consulado governamental africano contendo 25.000 registros. Algumas entradas identificavam locais de moradia emergencial de pessoas de uma população potencialmente vulnerável.
Um serviço canadense de imigração expunha quase 5.000 registros. A UpGuard afirmou que 884 incluíam senhas armazenadas em texto simples, o que significa que o aplicativo falhou tanto no controle de acesso quanto no tratamento de senhas.
Esses casos sustentam a conclusão mais ampla e também revelam diferentes camadas de falha. O acesso público às tabelas abriu a porta, mas um design fraco do aplicativo tornou o conteúdo mais perigoso.
A reportagem original afirmou que a maioria dos conjuntos de dados afetados parecia estar ligada aos Estados Unidos. Ainda assim, a UpGuard encontrou projetos expostos em todo o mundo e descreveu o problema como global.
A distribuição geográfica importa porque o Supabase funciona como infraestrutura comum para pequenos aplicativos, novos negócios e organizações estabelecidas. Um padrão de configuração repetido pode, portanto, afetar usuários sem relação entre si em vários setores e jurisdições legais.
Por Que o Banco de Dados Estava Acessível pela Web
A chave pública dentro de um aplicativo Supabase não é necessariamente a vulnerabilidade. O controle decisivo é o que essa chave tem permissão para fazer.
O Supabase oferece um banco de dados PostgreSQL hospedado, além de autenticação, armazenamento e interfaces de dados geradas automaticamente. Um aplicativo web pode fazer solicitações por meio de sua Data API usando uma chave publicável.
Às vezes, desenvolvedores presumem que encontrar essa chave no código do navegador prova que ela vazou. O Supabase projeta explicitamente chaves publicáveis para clientes públicos, incluindo sites e aplicativos móveis.
A proteção real vem de permissões e da Row Level Security, geralmente abreviada como RLS. A RLS é um recurso do PostgreSQL que aplica regras de autorização dentro do banco de dados antes de retornar ou alterar linhas individuais.
Um usuário autenticado pode receber permissão para ler apenas registros que contenham o identificador desse usuário. Um visitante não autenticado pode não receber acesso algum. Outra política pode permitir que todos leiam um catálogo de produtos deliberadamente público.
A documentação de segurança do Supabase afirma que os desenvolvedores devem ativar a RLS para tabelas expostas e configurar políticas de acordo com o princípio do menor privilégio. A chave publicável é considerada segura apenas quando esses controles restringem corretamente o acesso.
A plataforma também oferece chaves secretas ou de função de serviço para sistemas de backend confiáveis. Essas chaves ignoram a RLS e nunca devem aparecer em um navegador, aplicativo distribuído ou repositório público.
Essa arquitetura cria uma fronteira de segurança sutil. Uma chave publicável visível é esperada, mas também fornece a um visitante não autenticado uma rota para tudo o que o banco de dados permite que a função anon acesse.
Se uma tabela não tiver RLS, possuir permissões excessivas ou usar uma política que permita todas as linhas, uma pessoa externa poderá consultá-la pela mesma interface utilizada pelo aplicativo legítimo. Nenhuma invasão sofisticada é necessária.
Os pesquisadores da UpGuard encontraram projetos-alvo examinando JavaScript entregue publicamente em busca de identificadores do Supabase. Em seguida, podiam perguntar a cada banco de dados se uma tabela comum estava disponível por sua interface pública.
Essa técnica se assemelha ao comportamento normal de um aplicativo. A diferença está em quem envia a solicitação e se o banco de dados consegue distinguir um usuário autorizado de qualquer outra pessoa na internet.
A orientação detalhada sobre RLS do Supabase alerta que uma tabela em um esquema exposto pode ser legível ou gravável quando a RLS está ausente e a função solicitante possui as permissões adequadas. Ela recomenda testar tanto operações permitidas quanto negadas para funções anônimas e autenticadas.
É por isso que apenas rotacionar uma chave publicável não resolve o problema subjacente. A nova chave continua recuperável pelo cliente, enquanto a política defeituosa do banco de dados segue concedendo acesso.
Em vez disso, desenvolvedores precisam revisar esquemas expostos, permissões de tabelas, status da RLS, condições de políticas, visualizações de banco de dados e credenciais de servidor. Eles também precisam de testes que confirmem que usuários não podem ler ou alterar os registros de outro usuário.
As visualizações merecem atenção especial. Por padrão, visualizações do PostgreSQL podem avaliar permissões por meio de seu proprietário, potencialmente contornando restrições que protegem as tabelas subjacentes. Portanto, um projeto pode ativar a RLS em todos os lugares e ainda assim divulgar dados por uma visualização insegura.
A mesma distinção se aplica à autenticação. Exigir que alguém faça login não mantém automaticamente os locatários separados. Cada usuário autenticado ainda pode obter amplo acesso se a política apenas verificar a existência de uma sessão válida.
A segurança do Supabase explicada no nível das chaves é, portanto, simples. Clientes públicos precisam de um identificador público, enquanto as políticas do banco de dados impõem a fronteira real. A dificuldade está em traduzir as regras pretendidas do aplicativo em políticas completas e testadas.
Vibe Coding Transforma uma Lacuna de Configuração em um Padrão Repetido
Os riscos de segurança do vibe coding crescem quando um assistente de IA otimiza um resultado visível enquanto a autorização permanece invisível para a pessoa que o orienta.
Uma equipe de desenvolvimento convencional também pode configurar incorretamente um banco de dados. Buckets públicos do Amazon S3, clusters Elasticsearch expostos e credenciais de nuvem vazadas já existiam muito antes de a IA generativa entrar no desenvolvimento de software.
O que muda com o vibe coding é a combinação de velocidade, acessibilidade e revisão limitada. Uma pessoa pode pedir um aplicativo em linguagem natural, aceitar código gerado, conectar um backend hospedado e fazer a implantação sem compreender as fronteiras de confiança.
O aplicativo pode parecer completo porque o cadastro funciona, os registros são salvos corretamente e as páginas carregam. Esses testes confirmam a funcionalidade. Eles não confirmam que uma conta não consegue consultar os registros de outra conta.
Falhas de autorização são especialmente fáceis de ignorar em uma demonstração de caminho feliz. O desenvolvedor vê o perfil esperado após fazer login e presume que o sistema o protegeu. Um invasor faz uma pergunta diferente: o que acontece quando a solicitação omite uma sessão ou altera um identificador de registro?
Agentes de programação por IA também interagem com a infraestrutura de forma programática. A UpGuard observou que o Supabase ativa a RLS por padrão para tabelas criadas por partes de seu painel, enquanto tabelas criadas programaticamente exigem cuidados adicionais.
Essa diferença pode se tornar relevante quando um agente cria um esquema de banco de dados por SQL ou uma API. Uma configuração de proteção vinculada a um fluxo de criação não cobre automaticamente todas as rotas de entrada na plataforma.
O Supabase reconheceu esse desafio mais amplo de usabilidade em sua revisão de segurança de 2025. A empresa afirmou que a RLS é flexível, mas pode ser complexa para desenvolvedores que ainda não conhecem o padrão.
Durante 2025, o Supabase adicionou padrões mais seguros e ampliou seu Security Advisor. Também deu aos projetos mais controle sobre a Data API, incluindo a opção de desativá-la ou expor um esquema personalizado em vez do esquema padrão public.
Essas mudanças ajudam, mas não eliminam projetos existentes nem corrigem todas as migrações geradas. Ferramentas de segurança podem sinalizar erros comuns, mas uma política pode continuar logicamente errada mesmo atendendo a uma verificação básica.
Uma regra gerada pode comparar o identificador errado, deixar de considerar um caminho de atualização ou proteger leituras enquanto permite gravações não autorizadas. Ela pode funcionar para uma tabela, mas deixar uma tabela relacionada pública.
O supervisor humano do agente precisa reconhecer que esse comportamento ausente existe. Um iniciante que não conhece RLS, concessões de função ou isolamento de inquilinos talvez nunca peça ao modelo para testá-los.
Isso cria uma assimetria entre construir e auditar. Gerar um recurso exige um único prompt. Comprovar que esse recurso lida com segurança com todas as identidades e operações requer um modelo de ameaças, testes negativos e um exame cuidadoso dos artefatos gerados.
Estudos anteriores sugerem que esse é um padrão recorrente, e não um resultado isolado de pesquisa. A UpGuard citou pesquisas envolvendo empresas da Y Combinator, aplicativos criados por plataformas de desenvolvimento com IA e sites independentes.
A Modern Pentest relatou que 28% das 107 startups da Y Combinator examinadas expunham informações pessoais por meio de configurações do Supabase. Outro estudo analisou 1.072 aplicativos criados por vibe coding e encontrou 39 com tabelas legíveis por meio de uma chave pública do Supabase.
As amostras e os métodos diferem, portanto seus percentuais não devem ser combinados. Ainda assim, cada investigação encontrou versões da mesma falha: informações de conexão visíveis ao cliente combinadas com permissões de banco de dados mais amplas do que a aplicação pretendia.
Um incidente de fevereiro de 2026 tornou as consequências particularmente visíveis. A empresa de segurança Wiz descobriu que o Moltbook, uma rede social apresentada como uma plataforma para agentes de IA, tinha um backend Supabase configurado incorretamente.
Segundo a investigação sobre o Moltbook, o banco de dados permitia acesso de leitura e escrita aos dados da plataforma. O material exposto incluía 35.000 endereços de e-mail e 1,5 milhão de tokens de autenticação de API.
A Wiz disse ter encontrado o problema ao analisar JavaScript do lado do cliente durante uma avaliação não intrusiva. A equipe do Moltbook protegeu o banco de dados em poucas horas após a divulgação.
O episódio ofereceu um exemplo conciso do atual dilema. A assistência de IA ajudou a criar um serviço que atraiu atenção rapidamente, mas o sucesso visível da aplicação ocultava uma falha crítica no controle do banco de dados.
Para organizações que avaliam software criado com IA, isso muda o significado de um protótipo funcional. Uma demonstração agora comprova menos sobre a prontidão para produção, porque a IA pode concluir fluxos de trabalho visíveis antes que alguém valide o modelo de segurança subjacente.
Uma base interna de conhecimento de engenharia pode ajudar as equipes a reter decisões de arquitetura e evidências de revisão. Ela não substitui testes de banco de dados, mas pode impedir que premissas de segurança desapareçam entre prompts e transferências de responsabilidade.
“Seguro por Padrão” Encontra a Responsabilidade Compartilhada
O principal conflito está entre padrões seguros da plataforma e um modelo de responsabilidade compartilhada que ainda deixa clientes inexperientes controlando configurações relevantes.
O diretor de segurança da informação do Supabase, Bil Harmer, disse à TechCrunch que a empresa não havia analisado a pesquisa da UpGuard antes de comentar. Ele afirmou que os projetos do Supabase são seguros por padrão e descreveu a segurança como uma responsabilidade compartilhada.
Essa posição reflete um modelo padrão de nuvem. O provedor protege sua plataforma hospedada e oferece controles de acesso. Os clientes decidem quais usuários e aplicações devem alcançar seus dados.
A distinção é válida. A UpGuard não relatou ter comprometido os sistemas corporativos do Supabase nem contornado uma política de RLS configurada corretamente. Os bancos de dados expostos pertenciam a clientes cujas configurações permitiam acesso mais amplo.
No entanto, os padrões não podem ser avaliados apenas na criação do projeto. Eles também incluem os caminhos práticos que pessoas e agentes de programação usam para criar tabelas, publicar APIs, copiar exemplos e implantar aplicações.
Um sistema pode começar seguro e depois se tornar exposto por meio de uma migração gerada por um agente. Ele também pode oferecer um fluxo seguro no painel enquanto um fluxo programático cria um estado de segurança diferente.
A expressão “seguro por padrão” precisa, portanto, de um limite definido. Ela significa que um novo projeto não expõe nada? Abrange todos os caminhos compatíveis de criação de tabelas? Alerta os usuários antes que dados de produção entrem em uma tabela sem RLS?
A responsabilidade compartilhada também pressupõe que cada parte compreenda sua atribuição. Engenheiros experientes de nuvem sabem que um identificador público de cliente deve ser combinado com autorização no lado do servidor. Muitos vibe coders não sabem disso.
Essa lacuna de conhecimento não torna a plataforma a única responsável pelos erros dos clientes. Mas aumenta a pressão sobre o Supabase e os provedores de programação com IA para tornar estados inseguros mais difíceis de criar e mais fáceis de detectar.
A plataforma já avançou nessa direção. O Security Advisor do Supabase verifica problemas comuns de banco de dados, enquanto sua lista de verificação para produção instrui os usuários a habilitar RLS em todas as tabelas relevantes e revisar as políticas.
Um projeto mais rígido poderia bloquear o acesso de produção a uma tabela desprotegida ou exigir uma substituição explícita. Essas medidas reduziriam exposições acidentais, mas também poderiam dificultar conjuntos de dados públicos legítimos e o desenvolvimento rápido.
O Supabase precisa equilibrar esses casos sem tratar toda tabela pública como uma vulnerabilidade. Um cardápio de restaurante, placar público ou diretório publicado pode permitir leituras anônimas de forma razoável.
A plataforma não pode inferir a intenção apenas pelo nome de uma tabela. Uma tabela users é mais suspeita do que uma tabela products, mas uma aplicação pode publicar intencionalmente perfis de usuários enquanto mantém os endereços de e-mail privados.
Ferramentas automatizadas enfrentam a mesma ambiguidade. Elas podem detectar que uma função anônima pode ler uma tabela. Determinar se esse acesso viola a promessa do produto exige contexto de negócio.
Esse é o dilema central. Políticas flexíveis de banco de dados permitem que desenvolvedores criem muitos tipos de aplicações, mas a flexibilidade abre espaço para erros silenciosos. Restrições opinativas evitam erros, ao mesmo tempo que limitam projetos legítimos.
Assistentes de IA acrescentam outra parte responsável. Um desenvolvedor pode escolher o Supabase porque um agente o recomendou e, em seguida, confiar nesse agente para gerar o esquema e as políticas.
O provedor do modelo não hospeda o banco de dados, enquanto o Supabase não controla todos os comandos gerados. O proprietário da aplicação continua responsável perante os usuários, mesmo quando não consegue explicar o modelo de autorização resultante.
Essa cadeia fragmentada torna falhas de segurança mais difíceis de atribuir e mais fáceis de repetir. Cada participante pode apontar para a documentação ou para a configuração de outra parte, enquanto a pessoa afetada apenas vê que informações privadas se tornaram públicas.
Para compradores corporativos, a resposta prática é avaliar o sistema de desenvolvimento completo. Certificações de fornecedores importam, mas também importam controles de implantação, revisão de código, testes de banco de dados, registros, resposta a incidentes e a experiência das pessoas que supervisionam agentes de IA.
O Que os Números Mostram, e o Que Não Mostram
O estudo demonstra uma grande superfície de exposição, mas sua metodologia não estabelece 16.326 violações confirmadas nem mede toda a base de clientes do Supabase.
A UpGuard começou com domínios que apresentavam indicadores de uso do Supabase, e não com uma amostra aleatória de todas as aplicações na plataforma. Suas fontes favoreciam sites visíveis em conjuntos de dados de tecnologias web.
Os pesquisadores então consultaram uma tabela chamada users. Essa escolha fez sentido porque muitas aplicações mantêm registros de usuários, mas também direcionou a pesquisa para bancos de dados com maior probabilidade de conter informações pessoais.
A UpGuard divulgou essa limitação. A empresa afirmou que seus resultados tendiam a incluir PII em parte porque escolheu deliberadamente uma tabela comum associada a pessoas.
O total de 16.326 cobre bancos de dados que expõem tabelas legíveis. Isso não significa que todas as tabelas continham registros confidenciais. Alguns projetos podem ter publicado dados intencionalmente, usado informações sintéticas ou sido abandonados.
A análise de esquema também mede a exposição potencial de forma diferente de uma investigação forense registro por registro. Uma coluna chamada password é um alerta sério, mas sua existência por si só não prova que ela continha credenciais ativas.
Os pesquisadores validaram manualmente casos selecionados e relataram contagens concretas de registros desses bancos de dados. Esses exemplos mostram que pelo menos algumas exposições envolveram dados reais e sensíveis em escala significativa.
A pesquisa também não consegue determinar quantas pessoas externas acessaram os bancos de dados antes da divulgação. A disponibilidade pública cria risco, mas não prova que agentes criminosos descobriram ou baixaram as informações.
Essa diferença separa uma exposição de dados de uma violação de dados confirmada. Uma exposição significa que o acesso não autorizado era possível. Uma violação geralmente requer evidência de que uma parte não autorizada realmente acessou ou adquiriu os dados.
As organizações não devem usar essa distinção para minimizar o evento. Quando registros sensíveis podem ser acessados sem autorização adequada, os investigadores podem não dispor de registros suficientes para provar quem os acessou.
O estudo também não calcula uma taxa de exposição entre todos os projetos Supabase. A UpGuard analisou cerca de 300.000 domínios candidatos, enquanto uma organização pode operar vários domínios ou projetos.
Sites inativos e indicadores tecnológicos falsos podem complicar esse denominador. O número final é mais bem entendido como uma população descoberta, e não como um percentual de clientes do Supabase.
Mesmo com essas ressalvas, 16.326 bancos de dados legíveis representam uma superfície de ataque substancial. Um agente malicioso poderia automatizar o mesmo processo geral de descoberta e priorizar tabelas com campos valiosos.
Os casos detalhados também enfraquecem o argumento de que se tratavam de projetos de demonstração inofensivos. Registros de imigração, locais de moradia de emergência, comunicações privadas de adultos, placas de veículos e códigos de uso único têm claras implicações de privacidade e segurança.
A resposta do Supabase merece igual precisão. A empresa afirmou que notifica os clientes afetados quando toma conhecimento de problemas de segurança. Isso não confirma quantos projetos foram notificados, quão rapidamente responderam ou quantas exposições permaneceram abertas.
A UpGuard afirmou ter notificado os proprietários das aplicações nos casos significativos que validou. Seu relatório público não forneceu uma taxa completa de correção para todos os 16.326 bancos de dados.
Essas lacunas devem orientar a cobertura das conclusões. As evidências sustentam a existência de um problema generalizado de configuração e várias exposições graves. Elas não sustentam a alegação de que o próprio Supabase foi invadido ou de que todos os bancos de dados identificados vazaram registros sensíveis.
Isso também deixa sem resposta uma importante questão comparativa. Bancos de dados hospedados comparáveis poderiam apresentar problemas semelhantes se pesquisadores aplicassem um método equivalente em escala de internet.
Firebase, Appwrite, implantações autogerenciadas de PostgreSQL e outros serviços de backend expõem interfaces diferentes e usam modelos de permissão distintos. Desenvolvedores podem configurar incorretamente qualquer um deles.
O Supabase atrai atenção porque sua arquitetura amigável ao cliente, APIs automáticas e popularidade em fluxos de programação com IA tornam o problema visível. A popularidade aumenta tanto o número de implantações seguras quanto o número de erros.
Uma avaliação justa deve, portanto, evitar enquadrar o Supabase como singularmente incapaz de proteger dados. A conclusão mais forte é que sua adoção entre criadores inexperientes torna a usabilidade do controle de acesso uma preocupação no nível da plataforma.
Três Sinais Mostrarão se o Risco Está Diminuindo
A próxima fase deve ser avaliada por meio de mudanças mensuráveis no produto, evidências de correção e novos testes independentes, e não por promessas amplas de segurança.
O primeiro sinal é como o Supabase lida com tabelas criadas programaticamente. Agentes de programação trabalham com frequência por meio de SQL, interfaces de gerenciamento e migrações automatizadas, em vez de cliques manuais no painel.
Uma mudança significativa tornaria RLS e concessões restritivas consistentes entre os caminhos de criação, ou exigiria uma decisão explícita antes que uma tabela se tornasse acessível por meio da Data API. Avisos claros dentro dos fluxos de trabalho de agentes fortaleceriam essa proteção.
Se a Supabase reduzir a lacuna entre a criação via painel e a criação programática, isso reforçaria a visão de que padrões mais seguros podem reduzir os riscos de segurança do vibe coding. Se os fluxos de trabalho continuarem diferentes, criadores inexperientes seguirão entrando em estados inseguros sem reconhecê-los.
O segundo sinal são os dados de remediação. A Supabase e a UpGuard podem esclarecer quantos projetos identificados receberam notificações, quantos proprietários responderam e quantos bancos de dados deixaram de expor registros não intencionais.
Uma alta taxa de remediação mostraria que notificações e ferramentas de segurança podem reduzir o acúmulo existente. Uma taxa baixa sugeriria que muitos projetos foram abandonados, têm manutenção inadequada ou são operados por pessoas incapazes de corrigir a configuração.
As organizações afetadas também devem determinar se os registros expostos exigem notificação aos usuários ou comunicação aos órgãos reguladores. Essa decisão depende da localização, do tipo de dados, das evidências de acesso e da legislação aplicável.
O terceiro sinal é a realização de novos testes independentes ao longo dos próximos meses. Pesquisadores devem repetir varreduras comparáveis e publicar métodos transparentes que distingam dados públicos intencionais de exposições sensíveis.
Uma queda na quantidade de bancos de dados sustentaria a estratégia de padrões mais seguros da Supabase. Uma contagem estável ou crescente indicaria que o crescimento da plataforma e o desenvolvimento assistido por IA estão criando projetos inseguros mais rapidamente do que os controles existentes conseguem corrigi-los.
Os provedores de programação com IA também merecem escrutínio durante esses novos testes. Seus agentes devem criar políticas de privilégio mínimo, gerar testes negativos de autorização e alertar quando uma implantação expõe informações pessoais.
Os desenvolvedores não precisam abandonar a Supabase nem a programação com IA para responder de forma responsável. Precisam tratar o software gerado como não confiável até que seu comportamento de autorização seja testado.
Isso significa verificar separadamente o acesso anônimo e autenticado, testar todas as operações do banco de dados, revisar visualizações, proteger chaves de servidor e desativar interfaces de que o aplicativo não precisa.
As equipes também devem preservar as decisões por trás desses controles. Uma base de conhecimento com IA pesquisável pode conectar requisitos, migrações geradas, conclusões de auditoria e trabalhos de remediação, sem transformar a documentação em algo secundário.
A história da exposição de dados da Supabase é, em última análise, sobre uma lacuna de responsabilização. As plataformas oferecem controles configuráveis, agentes de IA montam aplicativos e os usuários confiam na interface finalizada.
Quem verifica as permissões invisíveis antes que informações reais entrem no sistema? Toda organização que lança um aplicativo gerado por IA deveria conseguir responder a essa pergunta com resultados de testes, responsáveis nomeados e evidências de acesso negado.
