--- title: "O Supabase é seguro? O que cobre e o que lhe cabe a si" description: "O Supabase tem SOC 2 Type 2 e ISO 27001, com cifragem em repouso e em trânsito. Os seus dados estarem seguros depende de definições que só você controla." url: "https://madsalt.tech/pt/blog/is-supabase-secure/" author: "Denys Zaichenko" language: "pt" published: 2026-10-26 --- # O Supabase é seguro? O que cobre e o que lhe cabe a si 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](https://supabase.com/security) e a [documentação de segurança](https://supabase.com/docs/guides/security) 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](https://supabase.com/docs/guides/security/soc-2-compliance) 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](https://supabase.com/docs/guides/deployment/shared-responsibility-model) 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 protege cada passo de um pedido. O Supabase trata do transporte e das chaves; os grants e as políticas são seus. A partir de um browser: Browser → TLS, chave · Supabase → Grant · você → RLS · você; A partir do seu servidor: Servidor → TLS · Supabase → Secret key · você → RLS ignorado.](https://madsalt.tech/charts/pt/is-supabase-secure.svg) *Figura 1. Com base no modelo de responsabilidade partilhada do Supabase e no seu guia de API keys, outubro de 2026.* 1. **Quem pode tocar numa tabela.** Os grants decidem se `anon` e `authenticated` chegam sequer a uma tabela. As políticas de RLS decidem que linhas. 2. **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](https://madsalt.tech/pt/blog/supabase-anon-key-vs-service-role-key/). 3. **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. 4. **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](https://mattpalmer.io/posts/2025/05/statement-on-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](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) 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](https://madsalt.tech/pt/blog/supabase-october-30-grant-change/). ## 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](https://madsalt.tech/pt/tools/supabase-security-check/) 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](https://madsalt.tech/pt/blog/lovable-app-security-checklist/). - 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](https://madsalt.tech/pt/blog/how-to-test-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](https://madsalt.tech/pt/#contact)