Em resumo
Sim, a plataforma é segura: o Supabase tem SOC 2 Type 2 e ISO 27001, cifra os dados em repouso com AES-256 e em trânsito com TLS, e assina acordos HIPAA no plano Team e superiores. O seu projeto é outra pergunta. No modelo de responsabilidade partilhada do Supabase, o acesso às tabelas, as API keys e as definições de auth são seus, e a plataforma faz exatamente o que essas definições dizem. Na minha tabela de teste local, uma só definição decidiu se uma chave pública obtinha 0 linhas ou as 3.
Sou o Denys, engenheiro full-stack e de IA, e a maioria das apps que construo ou corrijo corre em Supabase. Os clientes perguntam “o Supabase é seguro?” quando querem dizer “os meus dados estão seguros?”. São perguntas com respostas diferentes, por isso este artigo trata delas uma de cada vez.
A plataforma Supabase é segura?
O lado da plataforma é auditado por terceiros. Segundo a página de segurança e a documentação de segurança do Supabase, lidas a 23 de outubro de 2026:
| Controlo | O que o Supabase declara |
|---|---|
| SOC 2 Type 2 | Auditado todos os anos; o relatório está disponível para clientes Team e Enterprise |
| ISO 27001 | Certificado; o certificado está disponível para clientes Team e Enterprise |
| HIPAA | Suportado com um Business Associate Agreement assinado e o complemento HIPAA, plano Team e superiores |
| Cifragem | AES-256 em repouso, TLS em trânsito; os tokens de acesso e as chaves são também cifrados ao nível da aplicação |
| Cópias de segurança | Diárias nos projetos pagos; Point in Time Recovery como complemento a partir do plano Pro |
| Residência de dados | A base de dados, o Auth e o Storage ficam na região da AWS que escolher |
Nada disto protege uma tabela que deixou aberta. O guia de SOC 2 di-lo com clareza: a conformidade do Supabase não se transfere para nada que esteja fora do seu controlo.
O que lhe cabe a si?
O modelo de responsabilidade partilhada do Supabase enumera o que é sempre seu: a sua conta, a gestão de acessos à base de dados e às tabelas, os seus dados e a aplicação dos controlos de segurança, incluindo os avisos que o Security Advisor levanta. Na prática, são quatro camadas de definições:
- Quem pode tocar numa tabela. Os grants decidem se
anoneauthenticatedchegam sequer a uma tabela. As políticas de RLS decidem que linhas. - Que chave vai onde. A publishable key é pública por desenho, a secret key ignora o RLS. Comparei-as em Supabase anon key vs service role key.
- Definições de auth. Confirmação de email, leaked password protection (plano Pro e superiores), comprimento mínimo da palavra-passe, MFA, redirect URLs, CAPTCHA.
- Tudo o que rodeia a base de dados. Os buckets de Storage e as suas políticas, as funções
SECURITY DEFINER, as Edge Functions que usam a secret key e que schemas a Data API expõe.
Quanto muda uma só definição?
Executei o mesmo pedido contra uma tabela de três encomendas falsas numa stack local do Supabase (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), com a publishable key, como o faria um browser:
| Definição da tabela | O que a chave pública obteve |
|---|---|
| RLS desligado | As 3 linhas, e um insert devolveu 201 Created |
| RLS ligado, sem política | [] |
RLS ligado, política using (true) |
As 3 linhas |
Sem grant para anon |
42501 permission denied |
Mesma plataforma, mesma cifragem, mesmas certificações. A diferença é uma linha de SQL. É por isso que uma “plataforma segura” e uma app que deixa fugir dados não se contradizem: o CVE-2025-48757 encontrou 170 de 1645 apps de demonstração do Lovable a servir dados à chave pública, todas na mesma plataforma auditada.
O Supabase está a ficar mais seguro por omissão?
Sim, por passos. O changelog do Supabase de 28 de abril de 2026 enumera um interruptor para ter o RLS ligado por omissão, um selo de exposição da Data API, grants granulares por tabela e uma restrição à enumeração de schemas. O maior chega a 30 de outubro de 2026: as tabelas novas dos projetos existentes deixam de receber grants da Data API automaticamente, por isso uma tabela esquecida devolve 42501 em vez das suas linhas. As tabelas existentes mantêm os grants, por isso isto não corrige nada que já esteja aberto. As chaves antigas anon e service_role também serão dadas por obsoletas até ao fim de 2026 em favor das publishable e secret keys; a nova secret key recusa pedidos de um browser.
O que mais a mudança parte e como verificar o projeto antes: Supabase, 30 de outubro: o que falha com os novos grants.
Como verificar o seu próprio projeto?
Comece pelo Security Advisor do Supabase e corrija todos os avisos. Depois verifique o que ele não cobre:
- Execute a Auditoria de segurança Supabase gratuita. Liga-se só em leitura e classifica o projeto com 46 regras alinhadas com o OWASP Top 10:2025: RLS, políticas, vistas, funções, grants, storage e definições de auth, com o SQL de correção para cada achado.
- Teste com dois utilizadores de duas empresas. Nenhum scanner sabe que linhas pertencem a quem; o teste está na minha lista de segurança para apps Lovable.
- Se a sua app tem funções e um ecrã de permissões, prove que cada caixa de permissão faz o que diz, como em como testar o Supabase RLS.
Resumindo: o Supabase é um lugar seguro para guardar dados e dá-lhe as ferramentas para os manter privados. Se continuam privados decide-se no seu schema e nas suas definições.
A ponderar o Supabase para um projeto?
Gostava de trocar impressões sobre o que configurar primeiro. Sem pitch.
Fale comigo