RLS no Supabase: proteja o SaaS já hoje
Entenda por que as políticas do Supabase são essenciais, aprenda a evitar falhas comuns em SaaS e implemente segurança eficaz nas tabelas do seu banco.
Por que isso é importante
Políticas de cache: TTL e invalidação — header “bonito” sem fonte da verdade vira bug.
Leitura relacionada: Curso Next.js · Curso React · shadcn tutorial · Cursos CrazyStack.
O que é Row Level Security (RLS) no Supabase
RLS, ou Row Level Security, é um recurso que protege cada linha da sua tabela no
Supabase/Postgres. Quando ativada, apenas registros que atendem às regras de segurança
definidas podem ser acessados ou modificados por determinado usuário.
Atenção
Apenas ativar o RLS não basta: é necessário criar políticas claras para liberar ou
restringir ações na tabela!
Por que muitos projetos SaaS ficam expostos
É comum encontrar projetos usando Supabase sem encadeamento correto de políticas. Muitas
vezes, apps vão para produção sem configurações mínimas de proteção, resultando em APIs
completamente abertas a qualquer um que adivinhe a URL e a chave.
Erro crítico
Toda tabela sem RLS ativado está PUBLICAMENTE ACESSÍVEL. Qualquer pessoa pode ler,
alterar ou destruir estes dados.
Como funciona a exposição de dados no Supabase
Supabase utiliza uma API REST onde o endpoint, nomes de tabelas e chaves públicas ficam
aparentes nas requisições de rede. Estas informações, por si só, não representam risco.
O perigo está em tabelas ou endpoints sem políticas de acesso, pois qualquer usuário
pode manipular os dados.
Dica de segurança
O segredo não é esconder sua API key pública ou endpoint. O verdadeiro perigo é deixar
tabelas sem políticas de segurança ativadas.
Demonstração prática: diferença entre tabelas protegidas e expostas
Ao inspecionar o app pelo navegador, qualquer pessoa pode simular requisições para
acesso ao banco. Quando uma tabela está sem RLS, basta passar a chave pública correta
para ter acesso total. Em contrapartida, ao ativar RLS, todo acesso deve ser autorizado
por políticas, independentemente do uso de token público ou tools como Postman ou HTTP
client!
- Passo 1: Analise a tabela de funcionários sem RLS: qualquer
chamada autenticada expõe todos os dados. - Passo 2: Acesse uma tabela protegida com RLS: sem políticas,
nenhuma informação será retornada em qualquer tentativa. - Passo 3: Tente autenticar com tokens via client: sem RLS e
políticas, acesso ilimitado; com RLS, acesso negado.
Configuração de RLS e diferença entre “ativar” e “criar política”
Ativar RLS faz com que a tabela pare de liberar dados automaticamente, mas nada será
lido/escrito até que políticas explícitas sejam adicionadas. Há diferença entre “RLS
ativada” e “política criada”: só criar a política viabiliza acesso granular controlado.
Atenção ao detalhe
Política ativada sem nenhuma regra criada significa que NENHUMA leitura ou escrita
será possível (nem mesmo usuários autenticados terão acesso).
Como criar políticas de acesso seguro no Supabase
Ao criar uma política em sua tabela, você decide: quais operações cada usuário pode
executar e sob quais condições. O mais comum é liberar leitura apenas para usuários
autenticados.
- Passo 1: No painel do Supabase, ative o RLS para a tabela alvo.
- Passo 2: Clique em “Criar política”, defina nome e escolha a
operação (select, insert, update, delete). - Passo 3: Defina o público-alvo: geralmente “authenticated” para
usuários logados. - Passo 4: Use a expressão adequada no campo “Using”, como true (abrindo para qualquer autenticado) ou regras específicas
para restringir por proprietário.
Restrinja o acesso: só o dono do dado pode ler registro sensível
Apenas liberar para autenticados não é suficiente: qualquer usuário do sistema poderia
enxergar dados de outros. O ideal é criar regras para que somente o dono (user_id) do
registro consiga acessá-lo.
Melhore sua política
Troque a condição no campo “Using”: de true para algo como user_id = auth.uid() . Assim, apenas quem é dono de determinado dado
recupera aquele registro.
Como o token de acesso funciona em APIs protegidas
Depois de autenticado, o usuário recebe um access token . Para conseguir
acessar dados protegidos, qualquer requisição precisa enviar esse token como
“Authorization” no header. Só assim a política de leitura (e outras) irá liberar as
informações de acordo com o dono do registro.
- Passo 1: Faça login pelo app e copie o access_token retornado.
- Passo 2: Use o token como Bearer no header Authorization nas
APIs protegidas. - Passo 3: Agora o Supabase identifica o usuário e libera apenas
os dados que a política permite.
Erros comuns e consequências de políticas mal configuradas
Erros como deixar tabelas inteiras sem RLS, criar políticas com true sem filtrar por usuário, enviar dados sensíveis sem restrição ou esquecer de limitar as
permissões de cada operação (leitura, escrita, atualização) podem causar vazamento de
informações, golpes e exclusão total do banco.
Alerta vermelho
Qualquer usuário autenticado pode acessar todos os registros sensíveis se você só
liberar SELECT para authenticated com “true” e não filtrar pelo proprietário.
Boas práticas ao modelar tabelas seguras
Sempre que criar uma tabela que contenha dados sensíveis, inclua um campo user_id associando aquele registro ao usuário criador. Assim, suas
políticas sempre terão uma condição para identificar o dono do dado.
Dica prática
Inclua user_id como campo obrigatório em todas tabelas de usuários. Isso é
indispensável para conseguir aplicar políticas restritivas por proprietário!
Cuidados extras: funções administrativas e manipulação via funções RPC
Tabelas extremamente protegidas não podem ser manipuladas nem por usuários autenticados,
só via funções administrativas (RPC). Essas funções são úteis para casos como
integrações com serviços externos (ex: Stripe) ou ações oriundas do backend da sua
aplicação.
Atenção extra
Mesmo com RLS, funções RPC executadas com permissão de serviço ou pelo administrador
conseguem modificar as tabelas. Planeje cuidadosamente cada permissão!
Ferramentas para testar e validar políticas de segurança
Use ferramentas como Postman, Insomnia, NHN ou o próprio painel do Supabase para testar
todos os tipos de requisições permitidas e bloqueadas, com e sem autenticação,
diferentes usuários e tokens.
Supabase UI
Gerencie seu banco, crie e teste políticas diretamente pelo painel oficial
Postman
Teste e simule todas as requisições HTTP, valide headers e diferentes tokens
NHN
Cliente HTTP open source para chamadas rápidas e automação de testes
Insomnia
Alternativa prática ao Postman para testar autenticação e manipular cabeçalhos
Checklist de Implementação de Políticas RLS no Supabase
- Ativou RLS em todas as tabelas sensíveis do seu projeto
- Criou políticas explícitas para cada operação: leitura, escrita, atualização e exclusão
- Utilizou campo user_id para restringir acesso ao proprietário do dado
- Testou, com diferentes usuários, a impossibilidade de acessar dados de outros
- Validou permissões usando ferramentas como Postman, Insomnia e painel Supabase
- Obrigou autenticação para qualquer operação nas APIs expostas
- Revisou integrações externas para evitar brechas via funções administrativas (RPC)
Perguntas frequentes
Políticas de cache: o que importa?
TTL, invalidação e quem é a fonte da verdade. Header decorativo não salva.
CDN vs app cache?
Camadas diferentes. Confundir gera bug fantasma.
Next.js?
Entenda o modelo da sua versão.
Como debugar?
Reproduza com cache bypass e headers.
Continue explorando
Continue: Curso Next.js · Curso React · shadcn tutorial · Cursos CrazyStack.
Perguntas frequentes
Políticas de cache: o que importa?
TTL, invalidação e quem é a fonte da verdade. Header decorativo não salva.
CDN vs app cache?
Camadas diferentes. Confundir gera bug fantasma.
Next.js?
Entenda o modelo da sua versão.
Como debugar?
Reproduza com cache bypass e headers.
O que é Row Level Security (RLS) no Supabase
RLS, ou Row Level Security, é um recurso que protege cada linha da sua tabela no Supabase/Postgres. Quando ativada, apenas registros que atendem às regras de segurança definidas podem ser acessados ou modificados por determinado usuário.
Por que muitos projetos SaaS ficam expostos
É comum encontrar projetos usando Supabase sem encadeamento correto de políticas. Muitas vezes, apps vão para produção sem configurações mínimas de proteção, resultando em APIs completamente abertas a qualquer um que adivinhe a URL e a chave.
Como funciona a exposição de dados no Supabase
Supabase utiliza uma API REST onde o endpoint, nomes de tabelas e chaves públicas ficam aparentes nas requisições de rede. Estas informações, por si só, não representam risco. O perigo está em tabelas ou endpoints sem políticas de acesso, pois qualquer usuário pode manipular os dados.
Como criar políticas de acesso seguro no Supabase
Ao criar uma política em sua tabela, você decide: quais operações cada usuário pode executar e sob quais condições. O mais comum é liberar leitura apenas para usuários autenticados.
Como o token de acesso funciona em APIs protegidas
Depois de autenticado, o usuário recebe um access token . Para conseguir acessar dados protegidos, qualquer requisição precisa enviar esse token como “Authorization” no header. Só assim a política de leitura (e outras) irá liberar as informações de acordo com o dono do registro.