Supabase RLS: auditoria manual ou scanner?

Row Level Security é a linha entre um projeto Supabase que protege seus dados e outro que os expõe silenciosamente. Quando RLS está bem configurado, seu banco de dados impõe regras de acesso no nível de linha, para funções sujeitas a RLS. As funções privilegiadas, incluindo a função de serviço, podem ignorar essas regras. Quando está mal configurado, as tabelas parecem protegidas enquanto as políticas deixam passar mais do que o pretendido.

Este artigo compara duas maneiras de executar uma verificação de segurança Supabase RLS: verificar as políticas manualmente e executar uma auditoria RLS automatizada. Ambos têm um lugar. Saber onde cada um deles falha é como você verifica se suas políticas de acesso ao banco de dados funcionam conforme o esperado.

RLS é um recurso do Postgres que Supabase expõe por tabela. Uma vez habilitada, uma tabela nega acesso de linha a funções sujeitas a RLS, a menos que uma política permita; proprietários de tabelas e funções com privilégios de bypass são exceções. As políticas são avaliadas em relação ao usuário atual, às suas declarações e à consulta que está sendo executada. O auth.uid() função é geralmente a âncora: uma política como using (auth.uid() = user_id) limita o acesso às próprias linhas do banco de dados do usuário conectado.

O modelo está limpo. Os fracassos não o são, porque raramente parecem fracassos.

Alguns padrões são responsáveis pela maioria dos problemas do RLS:

• RLS ativado em algumas tabelas, não em todas. Uma nova tabela adicionada após o lançamento ou criada por meio de uma migração pode ser enviada com RLS desativada. Cada linha pode ser lida por qualquer função com acesso à tabela.

• Uma política que é mais ampla do que diz. using (true) em uma política selecionada significa que todas as linhas estão visíveis. É fácil adicionar durante o desenvolvimento para depuração e esquecer de remover.

• O papel de serviço assumido em todos os lugares. O código do lado do servidor que usa a chave de função de serviço ignora totalmente o RLS. Se as solicitações voltadas ao usuário passarem por essa chave, as políticas nunca serão aplicadas.

• Políticas que verificam a coluna errada. auth.uid() = id em uma mesa onde id é a chave primária da linha, não o proprietário, nunca corresponderá à intenção. A política existe, retorna um erro ou um conjunto vazio e a superfície ainda se comporta.

• Atualizações e exclusões de banco de dados sem controles de acesso apropriados. Os desenvolvedores geralmente protegem a seleção completamente e deixam as políticas de gravação livres. Passar na verificação de leitura não diz nada sobre quem pode modificar a linha a seguir.

Nenhum deles se anuncia. Cada um mantém o aplicativo funcionando, e é exatamente por isso que sobrevivem à produção.

Uma auditoria manual é direta e não requer novas ferramentas. Você trabalha com as próprias políticas, tabela por tabela.

Comece listando todas as tabelas e confirmando que RLS está habilitado em cada uma. Depois, para cada tabela, enumere as políticas e mapeie-as de acordo com o acesso pretendido: quem deve ler, quem deve escrever e quem nunca deve tocar nelas. Leia cada expressão de política em relação à coluna que ela compara. Confirme se selecionar, inserir, atualizar e excluir possuem uma política que corresponda à função pretendida.

Em seguida, verifique o caminho do código. Determine qual chave seu aplicativo realmente usa para solicitações voltadas ao usuário e se alguma delas é executada por meio da função de serviço. Em seguida, escreva consultas de teste como usuários diferentes e confirme se os resultados correspondem às expectativas: um usuário deve ler suas próprias linhas e as de mais ninguém, e não deve ser capaz de atualizar uma linha que não seja de sua propriedade.

Vale a pena fazer revisão manual, e ela pega bastante. Ele também tem pontos cegos previsíveis.

• Ele testa o que você lembra de testar. Se você não pensar em tentar excluir como segundo usuário, poderá perder uma política de exclusão excessivamente ampla. Com RLS ativado, nenhuma política de exclusão aplicável significa que a exclusão foi negada.

• Envelhece. As políticas mudam à medida que recursos são adicionados. Uma revisão completa no último trimestre não diz nada sobre a tabela que você adicionou na semana passada.

• Depende da mesma pessoa que configurou as políticas. O construtor que redigiu a política tem menos probabilidade de identificar sua própria suposição.

• Precisa de evidências registradas. “Eu revisei e parecia certo” não deixa nada para trás: nenhuma evidência, nenhum escopo, nenhum artefato que você possa digitalizar novamente mais tarde.

A auditoria manual responde à pergunta "isso corresponde ao meu modelo mental do sistema?" Ele não prova, por si só, o que o banco de dados realmente retornará.

Uma verificação de segurança automatizada Supabase RLS funciona na outra direção. Ele exercita o projeto da mesma forma que um invasor ou cliente mal configurado faria e relata o que a camada de dados realmente permite.

Essa mudança é importante por três razões. Primeiro, ela escala a memória anterior: a verificação repete as verificações nas tabelas e nos endpoints disponíveis dentro do escopo configurado. Uma verificação externa não pode inspecionar todas as políticas sem acesso adequado. Em segundo lugar, produz provas com base nas quais você pode agir: a descoberta nomeia a tabela, o estado da política e a condição que a tornou acessível, para que você saiba o que mudar e por quê. Terceiro, é repetível. Uma verificação que você pode executar novamente transforma uma revisão única em verificação contínua.

O VICE verifica aplicativos da web e configurações do Supabase/RLS e, em seguida, relata as descobertas com as evidências por trás delas e orientações de correção para trabalhar. Você pode marcar uma correção e solicitar uma nova verificação, mas somente uma nova verificação comparável confirmará que o problema foi resolvido: a correção é verificada no mesmo escopo, não assumida na edição. As verificações e alertas programados suportam o monitoramento contínuo, portanto, uma tabela adicionada no próximo mês não reintroduz silenciosamente a lacuna.

A divisão do trabalho é direta. Execute a verificação automatizada para descobrir o que foi perdido na revisão manual e, em seguida, use uma passagem manual para confirmar a intenção por trás de cada política sinalizada pela verificação. A automação informa o que o banco de dados permite; você decide se essa permissão foi deliberada.

A pontuação de qualquer varredura descreve o escopo testado, não uma garantia de que um projeto seja totalmente seguro. Trate isso como um sinal de onde procurar, não como um certificado.

Se você estiver implantando um produto desenvolvido com Supabase e nunca auditou suas políticas, a resposta honesta é ambas, em ordem. Comece com uma verificação automática do RLS para ter uma imagem atual e baseada em evidências do que suas tabelas permitem. Em seguida, analise as descobertas manualmente, confirme a intenção de cada política e corrija aquelas que foram desviadas. Coloque a verificação automatizada em um cronograma para que novas tabelas e novas políticas recebam o mesmo escrutínio que as originais.

Ignorar qualquer uma das abordagens pode deixar uma política de acesso ao banco de dados que parece proteger os dados, mas ainda permite acesso não autorizado.

Inicie uma verificação gratuita em vice-platform.com para verificar seu site público antes de se inscrever. Uma varredura Supabase especializada requer um domínio verificado e uma assinatura paga ou crédito adquirido; sua cobertura depende do acesso configurado.