Supabase: autenticação, banco de dados e regras de acesso

Muitos projetos feitos com ajuda de IA, de protótipos a produtos pequenos, usam o Supabase como retaguarda. A promessa é atraente: banco de dados, login e API prontos, sem escrever um servidor. O preço dessa conveniência é uma regra que muita gente só descobre tarde: a segurança dos dados passa a morar dentro do banco.

Este texto explica as três peças principais do Supabase (banco, autenticação e regras de acesso) e como elas conversam. A base é a documentação oficial do Supabase e do PostgreSQL, consultada em 8 de outubro de 2026. Nomes de chaves e recursos mudam com frequência; confira a documentação antes de configurar um projeto.

O banco: um Postgres completo

Segundo a documentação, cada projeto Supabase recebe “um banco Postgres completo, não uma abstração do Postgres” (Supabase, Database). PostgreSQL (ou Postgres) é um banco de dados relacional de código aberto, usado há décadas em sistemas de todos os tamanhos.

Na prática, isso significa que você trabalha com tabelas, chaves estrangeiras, índices e SQL de verdade. Dá para editar pelo painel visual, pelo editor de SQL ou por conexão direta. A mesma página lista extensões que podem ser ativadas pelo painel, como pgvector (busca por vetores, útil em RAG), PostGIS (dados geográficos) e pg_cron (tarefas agendadas).

O banco também é a base dos outros serviços do Supabase, como autenticação, armazenamento de arquivos e funções.

A API gerada a partir das tabelas

O Supabase cria uma API REST a partir do esquema do seu banco, para você acessar os dados do navegador sem escrever código de servidor (Supabase, Data REST API). Essa camada é o PostgREST, descrito na documentação como uma camada fina sobre o Postgres. Quando você muda uma tabela, a API reflete a mudança.

Aqui está o ponto central do texto. Num sistema tradicional, o navegador fala com um servidor seu, e esse servidor decide o que cada usuário pode ver. No Supabase, o navegador fala quase direto com o banco. Se o banco não souber quem está pedindo e o que essa pessoa pode fazer, ele entrega o que for pedido.

Por isso a documentação diz que a API foi configurada para funcionar com o Row Level Security do Postgres. Antes de chegar a ele, é preciso entender como o banco sabe quem é o usuário.

Autenticação: o Supabase Auth

O Supabase Auth é o serviço de cadastro e login. A documentação lista os métodos suportados: senha, link mágico e código de uso único por e-mail, login social (Google, GitHub, Apple e outros), login único corporativo (SSO, inclusive SAML 2.0) e login por telefone por meio de provedores de SMS (Supabase, Auth).

Os usuários ficam no próprio banco do projeto, num esquema separado chamado auth. Você pode ligar esses registros às suas tabelas, por exemplo com uma tabela perfis cuja chave aponta para o id do usuário.

Quando alguém faz login, o Auth emite um JWT (JSON Web Token): um texto assinado digitalmente que carrega dados sobre o usuário. A assinatura permite verificar que ninguém alterou o conteúdo. Segundo a documentação, os campos mais importantes são sub, o id único do usuário, e role, o papel do Postgres usado ao aplicar as políticas de acesso (Supabase, JWT). Esses tokens têm vida curta e são renovados enquanto a pessoa usa o sistema.

As bibliotecas do Supabase enviam esse token em cada requisição. O banco, então, sabe quem está pedindo. A documentação resume: o token do Auth delimita o acesso ao banco linha por linha quando usado em conjunto com políticas de RLS.

Regras de acesso: Row Level Security

Row Level Security (RLS, segurança em nível de linha) é um recurso nativo do PostgreSQL. Ele restringe, por usuário, quais linhas uma consulta pode devolver e quais linhas um comando pode inserir, alterar ou apagar (PostgreSQL, Row Security Policies). Cada regra se chama política.

A documentação do Supabase usa uma imagem útil: uma política funciona como uma cláusula WHERE acrescentada automaticamente a toda consulta naquela tabela (Supabase, Row Level Security).

Três comportamentos do Postgres são importantes:

• Sem RLS ligado, vale o acesso amplo. Antes de ativar o recurso, todas as linhas ficam disponíveis para quem tem permissão SQL na tabela.
• RLS ligado sem política bloqueia tudo. Segundo o manual do PostgreSQL, se não existe política, vale uma regra de negação padrão: nenhuma linha é visível nem pode ser alterada.
• Políticas se somam. Políticas comuns (permissivas) são combinadas com “ou”; políticas restritivas, com “e”.

Um exemplo simples

Imagine uma tabela notas em que cada pessoa só pode ver e criar as próprias notas. Este é um exemplo ilustrativo da redação, no padrão descrito pela documentação:

alter table notas enable row level security;

create policy "ler as proprias notas"
on notas for select
to authenticated
using ( (select auth.uid()) = dono_id );

create policy "criar notas em nome proprio"
on notas for insert
to authenticated
with check ( (select auth.uid()) = dono_id );

O que cada parte faz:

• auth.uid() devolve o id do usuário que fez a requisição, tirado do JWT. Sem login, devolve vazio (null), e a comparação falha.
• to authenticated limita a política a usuários logados. O Supabase usa o papel anon para requisições sem login e authenticated para requisições com login.
• using define quais linhas existentes o comando enxerga ou pode atingir.
• with check define como precisa ser a linha nova ou alterada. Sem ele na política de inserção, nada impediria alguém de gravar uma nota com o id de outra pessoa.

A documentação do Supabase recomenda escrever uma política para cada operação (select, insert, update, delete) e lembra que um update só funciona como esperado se houver também uma política de select correspondente.

As chaves de API: qual pode ir para o navegador

O Supabase trabalha com dois tipos de chave (Supabase, API keys):

• Chave publicável (sb_publishable_..., sucessora da antiga chave anon). Tem baixo privilégio e, segundo a documentação, pode ser exposta. Tudo o que ela alcança é limitado pelo RLS.
• Chave secreta (sb_secret_..., sucessora da antiga service_role). A documentação é direta: ela ignora todas as políticas de RLS. Serve só para componentes de servidor.

A consequência é que a chave publicável no código do site não é, por si, um vazamento. O vazamento acontece quando há tabela exposta sem RLS, ou quando a chave secreta aparece no navegador, num repositório ou num log. Na data da consulta, a documentação informava que as chaves antigas anon e service_role estão sendo descontinuadas até o fim de 2026 e recomendava migrar para as novas.

Esse cuidado se conecta com o que discutimos em como criar ferramentas web com IA sem comprometer a segurança: código gerado por IA costuma funcionar no primeiro teste e falhar justamente na parte de permissões.

Erros comuns e como evitá-los

Com base nas recomendações da documentação oficial, estes são os pontos que mais pedem atenção:

• Tabela sem RLS num esquema exposto. A documentação do Supabase afirma que toda tabela de um esquema exposto precisa de RLS ligado; sem ele, qualquer papel com permissão pode ler e gravar.
• Achar que política tira permissão. Políticas filtram linhas; as permissões (grants) são verificadas à parte. A documentação recomenda revogar de anon e authenticated as permissões de que eles não precisam.
• Chave secreta no front-end. Use-a só no servidor, uma por componente, e troque-a se vazar.
• Esquecer o dono da tabela. No PostgreSQL, superusuários e papéis com o atributo BYPASSRLS sempre ignoram as políticas, e o dono da tabela normalmente também, a menos que se use FORCE ROW LEVEL SECURITY. Testar como administrador não prova que a regra funciona para o usuário comum.
• Políticas lentas. A documentação sugere criar índice nas colunas usadas nas políticas e envolver auth.uid() em select, para que o valor seja calculado uma vez por consulta, e não uma vez por linha.
• Não testar a negação. A documentação recomenda testar, para cada operação e papel, tanto o que deve ser permitido quanto o que deve ser negado, com a ferramenta pgTAP.

O que levar deste texto

• O Supabase entrega um Postgres completo com login e API prontos. A API deixa o navegador falar quase direto com o banco.
• Por isso, a autorização mora no banco: o JWT diz quem é o usuário, e as políticas de RLS dizem o que essa pessoa pode fazer em cada linha.
• Ligue o RLS em toda tabela exposta, escreva políticas por operação, revogue permissões desnecessárias e mantenha a chave secreta fora do navegador.
• Teste também o que deve ser bloqueado. Uma regra de acesso só está pronta quando você viu ela negar.