O que é Row Level Security (RLS) e como protege cada linha do PostgreSQL?

Publicado em 2026-10-20 por frfrand

RLS explicado con un ejemplo de pedidos y usuarios: políticas por fila, permisos SQL, auth.uid(), service role y errores de seguridad frecuentes.

Row Level Security (RLS) é uma função do PostgreSQL que permite definir quais linhas de uma tabela uma conta pode ler ou modificar de acordo com políticas de acesso. É especialmente útil quando uma aplicação armazena dados de muitos usuários ou empresas nas mesmas tabelas.

Imaginá uma tabela com pedidos de mil clientes. Todos podem utilizar a mesma aplicação, mas ninguém deveria ver as compras de outra pessoa. O RLS permite aplicar parte dessa separação diretamente onde vivem os dados.

O exemplo dos armários

Pensá em um edifício com um depósito comum. Cada cliente tem um compartimento identificado. A porta principal permite entrar no edifício, mas isso não significa que você pode abrir qualquer armário.

Em um banco de dados relacional, as permissões sobre a tabela se assemelham ao acesso geral ao depósito. As políticas RLS verificam quais linhas correspondem a cada identidade e operação.

A metáfora não é perfeita, mas ajuda a distinguir permissão para consultar uma tabela e permissão para consultar uma linha concreta.

O RLS substitui as permissões normais?

Não. O PostgreSQL utiliza privilégios sobre objetos e políticas sobre linhas. Ambas as camadas importam.

Se uma conta não tiver permissão para executar SELECT sobre uma tabela, adicionar uma política RLS não concede automaticamente esse privilégio. E se uma conta tiver privilégios amplos ou puder ignorar o RLS, também não convém assumir que uma política a restringirá.

No Supabase é especialmente importante revisar quais roles têm permissões sobre as tabelas expostas e quais políticas se aplicam.

Um exemplo com um aplicativo de agendamentos

Suponha que você tenha uma tabela reservas com campos id, usuario_id, data e estado.

Você quer que cada pessoa consulte suas reservas, mas não as de outros usuários. Uma política de leitura pode comparar o identificador do usuário autenticado com o campo usuario_id de cada linha.

O mecanismo específico depende de como a identidade chega ao banco de dados. No Supabase, por exemplo, são usadas funções como auth.uid() dentro das políticas.

A ideia é que o banco de dados filtre as linhas autorizadas, mesmo quando uma solicitação tenta consultar mais informações do que o devido.

E para atualizar ou inserir informações?

As políticas podem distinguir operações. Permitir ler uma reserva própria não significa permitir alterar seu valor, aprová-la em nome de um administrador ou criá-la para qualquer usuário.

É preciso definir regras para SELECT, INSERT, UPDATE e DELETE de acordo com o modelo de acesso.

Também convém evitar que uma pessoa altere o proprietário de uma linha para conseguir acesso posterior. O design deve contemplar tanto as linhas existentes quanto os valores novos.

RLS significa que já posso confiar no frontend?

Não. A interface ainda precisa de um design correto, e o servidor deve realizar verificações adicionais quando for o caso.

RLS protege operações sobre linhas dentro do PostgreSQL sob suas regras; não valida automaticamente pagamentos, envios de e-mail ou decisões complexas de negócios.

É uma camada de defesa particularmente valiosa quando existem APIs ou SDKs que permitem acessar determinadas tabelas a partir de clientes autenticados.

O que é service_role no Supabase?

O Supabase utiliza um papel de serviço com privilégios elevados que pode ignorar as políticas RLS. Por essa razão, as chaves de serviço devem permanecer do lado do servidor e sob controles de acesso apropriados.

Não é seguro colocar uma credencial com capacidade de pular as políticas dentro do JavaScript público de um site.

Nem confunda uma chave publicável do projeto com autorização universal: o acesso efetivo depende de papéis, políticas e configuração.

Erros frequentes

Criar a tabela e esquecer as políticas. Algumas configurações expõem dados se os privilégios o permitirem.

Aplicar apenas uma política de leitura. Inserir ou atualizar linhas pode exigir regras distintas.

Testar apenas com um administrador. Se essa conta evita o RLS, você pode pensar que tudo funciona e descobrir depois que os usuários reais não conseguem acessar ou acessam indevidamente.

Não verificar casos negativos. Os testes devem confirmar que o cliente A não pode ler nem modificar linhas do cliente B.

Como se encaixa no ArduMaker?

Se você implantar um banco PostgreSQL em um VPS gerenciado pelo ArduMaker, poderá utilizar recursos de segurança do próprio mecanismo, incluindo RLS quando apropriado. Mas configurar o servidor não define automaticamente as políticas do seu aplicativo: isso pertence ao projeto de dados e permissões.

Em resumo: o RLS ajuda a controlar o acesso linha por linha. Combinado com permissões SQL, autenticação e testes, pode ser uma defesa importante para aplicações multiusuário.

Fontes: RLS no PostgreSQL · RLS no Supabase Para que serve o Supabase.