Supabase RLS: proteja os dados do seu app e as chaves de API
Por Mauro Mequelussi · Curso gratuito Supabase sem mistério: banco, auth e RLS · Português (PT-BR)
Resposta direta · O que esta aula resolve
A Aula 9 de 15 ("Supabase RLS: proteja os dados do seu app e as chaves de API"), parte do módulo "Recursos avançados" do curso gratuito "Supabase sem mistério: banco, auth e RLS" na Escola de Aplicativos (ministrado por Mauro Mequelussi), ensina na prática: exploramos o funcionamento do Row Level Security (RLS) no Supabase usando a analogia do porteiro e as chaves de API. Veja como restringir o acesso no Funil para vendedores e donos, além de evitar armadilhas comuns como views desprotegidas e funções mal configuradas. Aprenda também a usar o Security Advisor para auditar a segurança do seu banco.
Crie sua conta grátis para assistir a esta videoaula em HD
O resumo técnico e os capítulos abaixo são abertos para consulta. Crie sua conta 100% gratuita em segundos para liberar todas as 15 videoaulas em HD, controle automático de progresso, Tutor IA e certificado gratuito verificável.
- R$ 0 · Sem cartão de crédito
- Tutor IA tira-dúvidas da aula
- Certificado gratuito incluso
O que você vai aprender
- A diferença essencial entre a chave de API publicável e a chave secreta.
- O funcionamento do Row Level Security e como estruturar políticas com filtros precisos.
- Por que TO authenticated sozinho não é seguro e a diferença entre autenticação e autorização.
- O papel das cláusulas USING e WITH CHECK em operações de atualização.
- Como views desprotegidas e funções SECURITY DEFINER podem ignorar o RLS acidentalmente.
- Como identificar e corrigir brechas com o Security Advisor do Supabase.
Pontos-chave da aula
- A chave pública no frontend abre apenas a porta do saguão; o RLS decide quem acessa cada linha.
- Uma política segura define sempre quem pode acessar e qual linha pertence àquela pessoa.
- Nunca confie no user_metadata para definir papéis de permissão; utilize app_metadata ou schemas privados.
- Para evitar desvios no UPDATE, combine sempre USING com WITH CHECK e garanta permissão de leitura.
- Ative security_invoker = true em views para que respeitem as políticas de RLS do usuário conectado.
Capítulos e roteiro técnico da aula
12 capítulos minutados- 00:00
A chave pública do app e o risco de vazamento
Entenda por que chaves no frontend são públicas e o que realmente protege os dados do seu banco contra acessos indevidos.
- 00:23
O que é RLS e a analogia do porteiro
Descubra como o Row Level Security atua como um porteiro decidindo quem acessa cada linha do banco de dados.
- 00:50
Como funcionam as políticas de acesso
Veja onde criar políticas no Supabase e como elas adicionam filtros automáticos em cada consulta executada.
- 01:14
Regra para vendedores: autenticação e autorização
Evite a armadilha de permitir acesso apenas por login sem checar se a linha realmente pertence ao usuário.
- 01:48
Acesso de administrador e metadados seguros
Saiba como conceder acesso total a administradores utilizando schemas privados e app_metadata em vez de user_metadata.
- 02:21
Políticas de edição com USING e WITH CHECK
Compreenda a importância de validar os dados antes e depois da edição para evitar roubo de linhas entre usuários.
- 02:51
Furos silenciosos: views, SECURITY DEFINER e chaves
Conheça as três brechas comuns que ignoram o RLS por acidente e aprenda como corrigi-las.
- 03:44
Auditoria prática com o Security Advisor
Use o painel do Supabase para encontrar tabelas expostas e testar regras de segurança antes de ir para produção.
- 04:19
Por que você nunca deve desligar o RLS
Aprenda a diagnosticar erros de permissão comuns como o erro 42501 sem abrir mão da segurança do projeto.
- 04:40
Comparativo: RLS contra regras no backend e Firebase
Entenda as vantagens de aplicar regras de segurança direto no PostgreSQL em vez de confiar apenas em código de aplicação.
- 04:57
Impacto em performance e boas práticas de índices
Dicas essenciais de indexação e consultas para garantir que o RLS não prejudique a velocidade do seu banco.
- 05:13
Resumo da aula e introdução a vetores e IA
Recapitulação dos pontos de segurança do app e uma introdução ao que será construído na próxima aula com IA.
Momentos de destaque na prática
A armadilha clássica do TO authenticated
Cuidado: permitir acesso a quem está logado não significa proteger os dados de outros usuários.
Como views e SECURITY DEFINER furam o RLS
Você sabia que uma consulta salva ou uma função podem desativar a segurança do seu banco sem você perceber?
Auditoria em segundos com o Security Advisor
Descubra como o painel do Supabase alerta sobre brechas críticas no seu banco com poucos cliques.
Notas de aula e guia de estudo
Nesta aula, desvendamos como proteger a aplicação contra acessos indevidos utilizando o Row Level Security (RLS) do Supabase. Você vai entender por que as chaves públicas no frontend são normais e como o banco de dados assume a responsabilidade de barrar quem não tem autorização. Além disso, analisamos as armadilhas comuns que causam vazamentos de dados silenciosos e como auditar seu projeto.
O que você vai aprender
- A diferença essencial entre a chave de API publicável e a chave secreta.
- O funcionamento do Row Level Security e como estruturar políticas com filtros precisos.
- Por que
TO authenticatedsozinho não é seguro e a diferença entre autenticação e autorização. - O papel das cláusulas
USINGeWITH CHECKem operações de atualização. - Como views desprotegidas e funções
SECURITY DEFINERpodem ignorar o RLS acidentalmente. - Como identificar e corrigir brechas com o Security Advisor do Supabase.
Pontos-chave
- A chave pública no frontend abre apenas a porta do saguão; o RLS decide quem acessa cada linha.
- Uma política segura define sempre quem pode acessar e qual linha pertence àquela pessoa.
- Nunca confie no
user_metadatapara definir papéis de permissão; utilizeapp_metadataou schemas privados. - Para evitar desvios no
UPDATE, combine sempreUSINGcomWITH CHECKe garanta permissão de leitura. - Ative
security_invoker = trueem views para que respeitem as políticas de RLS do usuário conectado.