FixVibe
Covered by FixVibehigh

Acesso não autorizado a dados por meio de segurança em nível de linha Supabase ausente (RLS)

Em aplicativos suportados por Supabase, a segurança de dados depende da segurança em nível de linha (RLS). Se RLS não estiver explicitamente habilitado e configurado com políticas, qualquer usuário com a chave pública anônima poderá ler, atualizar ou excluir dados em todo o banco de dados. Isso é particularmente crítico em ambientes Next.js onde o cliente Supabase é frequentemente inicializado com uma chave pública API.

CWE-284

Impacto

A falha na implementação da segurança em nível de linha (RLS) permite que invasores não autenticados consultem dados de um banco de dados Supabase quando tabelas públicas são expostas através do limite anon [S1]. Como os aplicativos Next.js normalmente expõem a chave Supabase anon no código do lado do cliente, um invasor pode usar essa chave para fazer chamadas REST API diretas ao banco de dados, ignorando a lógica do aplicativo pretendida e acessando informações confidenciais do usuário [S2].

Causa Raiz

Por padrão, as tabelas Postgres em Supabase exigem ativação explícita da segurança em nível de linha para impedir o acesso público [S1]. Quando um desenvolvedor cria uma tabela, mas se esquece de ativar RLS ou não consegue definir políticas restritivas, o banco de dados pode expor os dados a qualquer pessoa que possua a chave anon do projeto, [S1]. Em aplicativos Next.js, a renderização do lado do servidor e a busca do lado do cliente também exigem uma configuração cuidadosa do cliente Supabase para que o contexto do usuário autenticado alcance a camada de banco de dados [S2].

Correções de concreto

  • Ative RLS: Execute ALTER TABLE "your_table_name" ENABLE ROW LEVEL SECURITY; para cada tabela pública que armazena dados do aplicativo [S1].
  • Definir políticas: Crie políticas específicas que restrinjam o acesso com base no status de autenticação do usuário, como CREATE POLICY "Users can see their own data" ON your_table_name FOR SELECT USING (auth.uid() = user_id); [S1].
  • Clientes seguros do lado do servidor: Ao usar Next.js, mantenha os clientes com função de serviço apenas no servidor e ainda aplique filtros de propriedade antes de retornar dados aos usuários [S2].

Como FixVibe testa isso

FixVibe já executa uma verificação Supabase RLS somente leitura por meio de baas.supabase-rls. O scanner descobre o URL do projeto Supabase e a chave pública anônima de pacotes JavaScript da mesma origem, solicita ao PostgREST metadados de tabela pública e tenta seleções limitadas somente leitura para confirmar se os dados são expostos sem uma sessão do usuário. Ele não insere, atualiza, exclui ou usa credenciais de função de serviço. As varreduras de repositório também podem detectar isso anteriormente por meio de repo.supabase.missing-rls, que sinaliza migrações SQL que criam tabelas públicas sem ENABLE ROW LEVEL SECURITY.