O Supabase criptografa meus dados? Sim. Veja o que isso impede

Um cliente escreve perguntando se os dados dele estão criptografados. Ou um cliente maior manda um questionário de segurança numa planilha, e nele estão as linhas que todo questionário tem: criptografia em repouso, criptografia em trânsito, o relatório SOC 2 do seu provedor de hospedagem. O seu app roda no Supabase porque o Lovable ou o Bolt configurou assim, e até hoje ninguém precisava que você soubesse o que nada disso quer dizer.

Então, o Supabase criptografa os seus dados? Sim. Todos, em todos os planos, e os certificados por trás dessa afirmação são reais.

A maioria das respostas erra ao parar aí, como se a criptografia decidisse quem pode ler os seus dados. Ela decide algo mais estreito. Pense no Supabase como um banco. A criptografia em repouso é o cofre, a criptografia em trânsito é o carro-forte, e o SOC 2 é o inspetor que confere se os dois funcionam do jeito que o banco diz. Cada um trata de alguém que nunca deveria ter entrado. A regra do guichê, a que diz de quem um cliente pode pedir o extrato, é outra coisa, e ela é escrita no seu projeto.

Cada número abaixo foi lido nas páginas e na documentação do Supabase em 29 de setembro de 2026.

O Supabase criptografa meus dados?

Sim. A página de segurança do Supabase diz que todos os dados dos clientes são criptografados em repouso com AES-256 e em trânsito com TLS, e você não precisa ativar nada.

Em repouso quer dizer nos discos. O seu banco de dados é gravado no armazenamento de forma criptografada, então uma cópia do disco levada das máquinas do Supabase é ilegível sozinha.

Em trânsito quer dizer no caminho entre o seu visitante e o Supabase. O seu app conversa com o Supabase pelas APIs web dele, para dados, logins e arquivos, e o guia de obrigatoriedade de SSL do Supabase diz que cada uma dessas APIs recusa uma conexão sem criptografia. A exceção é uma conexão direta ao banco Postgres que fica por baixo, do tipo que uma ferramenta de backup ou um servidor seu pode abrir. Essas aceitam uma conexão sem criptografia até você ativar Enforce SSL on incoming connections em Database Settings. Os navegadores dos seus visitantes nunca abrem uma.

A criptografia de colunas é a única camada que fica desligada. Ela mantém um valor específico, um número de telefone por exemplo, embaralhado mesmo dentro do banco. O Supabase documentava um jeito de fazer isso, e a página do pgsodium agora desaconselha esse recurso, citando a complexidade operacional e o risco de configurá-lo errado, e acrescenta que a criptografia em repouso provavelmente basta para SOC 2 e HIPAA. Para segredos como a chave de API de um serviço externo existe o Vault, que os guarda criptografados e os devolve por meio de uma view.

Contra o que a criptografia do Supabase protege?

Contra qualquer um que chegue aos seus dados sem pedi-los ao banco. Quem leva um disco embora, copia um arquivo de backup ou escuta o tráfego entre um navegador e o Supabase recebe bytes embaralhados e mais nada.

Uma requisição que o banco decide responder é outra história. A criptografia em repouso trabalha por baixo do Postgres, então o banco lê os próprios arquivos em texto claro, para cada consulta que atende. Quais consultas ele atende é definido pelas permissões de cada tabela. No Supabase isso é a Row Level Security, a regra que diz quais linhas cada visitante pode ler, e cada tabela precisa dela ligada, com uma regra escrita para ela.

Esse é o guichê do banco. O cofre se abre para o caixa toda vez, porque o caixa trabalha para o banco. Se ninguém deixou escrito de quem um cliente pode ver os extratos, o caixa entrega o que for pedido, e o carro-forte leva, lacrado o caminho inteiro, até quem pediu.

A documentação do Supabase diz o mesmo sobre o Vault, que de fato criptografa valores dentro do banco: "qualquer pessoa que tenha acesso à view tem acesso aos segredos descriptografados."

A criptografia impede um estranho de ler minhas tabelas?

Não, e medimos com que frequência isso importa. Em agosto de 2026 escaneamos 30.998 apps publicados, feitos com Lovable, Base44, Replit, v0 e Bolt. Em 3.680 deles conseguimos concluir a verificação que pergunta a um banco Supabase, sem login, se uma tabela vai entregar suas linhas. Em 2.096, ou 57%, pelo menos uma tabela entregava, e 394 deles tinham uma tabela aberta com nome de pessoas: users, profiles, customers, orders.

Cada um desses bancos estava criptografado em repouso o tempo todo, pela própria descrição que a plataforma faz de como funciona, e qualquer estranho que pedisse teria recebido as linhas por TLS. Nada na criptografia falhou, e ela não teve papel nenhum em decidir quem recebia uma resposta.

A requisição em si é comum. É a mesma que o seu app faz para mostrar os pedidos a um cliente logado, enviada sem o login: a chave pública que deve estar na sua página, e um GET para /rest/v1/ com o nome de uma tabela no fim. O nosso scan leu quantas linhas cada tabela devolveria e parou ali, sem baixar nenhuma. A medição completa explica do que esses 57% são uma parte e quanto não conseguimos ver.

O Supabase está em conformidade com o SOC 2?

Sim. O Supabase tem um relatório SOC 2 Type 2 de um auditor independente, renovado todo ano.

Um relatório SOC 2 é o relato de um auditor sobre se os controles de segurança de uma empresa funcionaram do jeito que a empresa diz. Type 2 significa que eles foram testados durante um período inteiro, e o do Supabase vai de 1º de março a 28 de fevereiro. Ele cobre segurança, disponibilidade, integridade do processamento, confidencialidade e privacidade, no banco de dados, Storage, Auth, Realtime, Edge Functions e na Data API, e a página de SOC 2 do Supabase marca onde ele termina:

A conformidade SOC 2 do Supabase não se transfere para ambientes fora do produto Supabase ou fora do controle do Supabase.

No banco, é o relatório do inspetor sobre o cofre e os carros-fortes. As regras das suas tabelas ficam de fora, porque quem as escreve é você: o modelo de responsabilidade compartilhada do Supabase coloca a gestão de acessos e a aplicação de controles de segurança entre as coisas pelas quais o cliente é sempre responsável.

Daí saem mais duas coisas. Se um cliente precisa que a sua empresa esteja em conformidade com o SOC 2, a página de SOC 2 do Supabase diz que um cliente nessa situação tem de implantar os controles e passar pela própria auditoria. E se o Supabase é uma plataforma sólida para construir em cima é outra pergunta, com um artigo próprio.

Como consigo o relatório SOC 2 do Supabase?

No painel da sua organização, a partir do plano Team. Ele fica em Legal Documents, ao lado do certificado ISO 27001 e do questionário de segurança padrão do Supabase, e uma organização no Free ou no Pro encontra ali um botão de upgrade no lugar.

O Team começa em $599 por mês, enquanto o Pro começa em $25, então vale saber o que a diferença compra. A documentação do Supabase diz que todo projeto segue o mesmo conjunto de controles de conformidade, então um projeto no Pro roda na mesma plataforma auditada. O Team acrescenta os documentos, junto com login único para o painel, backups diários guardados por 14 dias onde o Pro guarda 7, e o acesso à HIPAA. Se um cliente pedir o relatório em si, pergunte se a página pública de segurança do Supabase basta antes de trocar de plano por um PDF.

O Supabase tem certificação ISO 27001?

Sim, pela ISO/IEC 27001:2022, o que o Supabase anunciou em 22 de abril de 2026.

A ISO 27001 certifica um sistema de gestão: as políticas, as avaliações de risco e os processos que uma empresa usa para cuidar das informações que guarda. Um auditor credenciado emite o certificado por três anos e volta todo ano nesse meio-tempo para conferir se o sistema continua funcionando. No banco, é o inspetor que examina como os procedimentos de segurança são definidos e mantidos em dia. O anúncio do Supabase descreve o SOC 2 como amplamente aceito na América do Norte e a ISO 27001 como amplamente aceita na Europa, na Ásia e no setor público. O certificado fica na mesma seção Legal Documents, nos mesmos planos.

O Supabase está em conformidade com a HIPAA?

Pode estar, para o seu projeto, depois que você assina um Business Associate Agreement com o Supabase e paga o add-on de HIPAA. Não é automático, e a página de SOC 2 do Supabase diz que o SOC 2 não o substitui.

Um Business Associate Agreement, ou BAA, é o contrato escrito que a lei de saúde dos Estados Unidos exige antes que uma empresa possa tratar informações de saúde protegidas em seu nome. O Supabase assina um a partir do plano Team. O add-on não tem preço publicado: você envia um pedido, o Supabase responde com o preço e o processo, e uma organização no Free ou no Pro que se candidata ainda precisa passar para o Team depois de aprovada.

A assinatura é onde começa a sua parte. O modelo de responsabilidade compartilhada do Supabase lista o que um cliente HIPAA precisa fazer, e estes são os itens que o dono de um app tem menos chance de já conhecer:

• Marcar o projeto como projeto HIPAA, e agir sobre o que o Security Advisor apontar sobre ele.
• Ativar o login em duas etapas em todas as contas da organização no Supabase.
• Ativar a recuperação a um ponto no tempo, que precisa de pelo menos o add-on de computação Small.
• Ativar a obrigatoriedade de SSL e as restrições de rede.
• Manter dados de saúde fora de buckets de armazenamento públicos.

A criptografia em repouso e em trânsito também está nessa lista, e é o único item que o Supabase já fez.

O Supabase está em conformidade com o GDPR?

O Supabase dá suporte a apps em conformidade com o GDPR e fornece as duas peças que só ele pode fornecer. Se o seu app está em conformidade depende do que ele faz com os dados das pessoas.

A primeira peça é o local. Você escolhe uma região ao criar um projeto, e uma região específica da UE mantém ali o seu banco de dados, o Auth e o Storage. Escolha a região pelo nome, porque a opção geral Europa do Supabase também inclui Londres e Zurique. A segunda é o Data Processing Addendum, o contrato de tratamento de dados que o GDPR exige entre você e uma empresa que trata dados pessoais por você. O do Supabase faz parte dos termos de serviço, então toda organização já tem um.

O resto fica com o seu app: por que você coleta cada campo, como as pessoas consentem, quem pode ler e como você apaga quando pedem. A página do GDPR do Supabase diz com todas as letras que escolher uma região não deixa uma aplicação em conformidade sozinha. O que o seu app deve perante a lei é uma pergunta para um advogado.

Como respondo ao questionário de segurança de um cliente?

Separe em duas pilhas antes de escrever qualquer coisa. Algumas linhas perguntam sobre a plataforma do Supabase e se respondem com os documentos do Supabase. As outras perguntam sobre o seu projeto, e você é a única pessoa que pode respondê-las.

As linhas do Supabase se copiam direto dos documentos dele. As três últimas são as que o cliente queria descobrir quando mandou o questionário, e respondê-las exige o seu próprio projeto aberto na sua frente.

O que digo a um cliente que pergunta quem pode ler os dados?

O estado das suas políticas, tabela por tabela, e a data em que você as verificou pela última vez. "Os dados são criptografados" responde a uma pergunta sobre discos roubados, e um cliente que pergunta sobre acesso está perguntando sobre o guichê.

Uma resposta direta nomeia as tabelas que guardam dados pessoais e diz que cada uma tem a Row Level Security ligada, com uma política que prende cada linha à pessoa logada a quem ela pertence. Diz quando você verificou pela última vez, de fora, como visitante sem login, que essas tabelas não devolviam nada. Se uma tabela é pública de propósito, uma lista de produtos ou posts publicados, ela diz isso também. Depois, o lado administrativo: quem pode abrir o seu painel do Supabase, com verificação em duas etapas, e onde fica a chave secreta. Essa chave se chama service_role nos projetos mais antigos e sb_secret_… nos mais novos, e o lugar dela é num servidor.

Para descobrir o estado das suas tabelas, comece pelo Security Advisor no seu painel do Supabase, que lista cada tabela com a Row Level Security desligada. Uma tabela pode passar nessa verificação e continuar aberta, por uma política que deixa todo mundo entrar. Os quatro estados em que uma tabela pode estar mostram como diferenciá-los, e há um guia em linguagem simples para apps Supabase.

Ponha por escrito só o que você verificou. Se ainda não leu a política de uma tabela, diga a data até a qual vai ler.

Como o Reeve confere a resposta de fora

As linhas que um questionário deixa para você tratam de quem recebe uma resposta. O Reeve pergunta ao seu app publicado do jeito que um estranho perguntaria e diz quais tabelas responderam.

• O scan gratuito pergunta a cada tabela que o seu app cita quantas linhas um visitante sem login receberia, lê o número e para sem baixar nenhuma linha. Uns 20 segundos, sem conta: escaneie o seu app.
• O Reeve Monitor refaz as nove verificações a cada hora em até três apps e manda um e-mail no dia em que a sua nota piora, então uma tabela que o seu builder adicionar depois que o questionário voltou é verificada em até uma hora.
• O Care faz as mesmas verificações e guarda uma cópia do seu banco de dados Supabase fora da sua conta no Supabase, feita numa programação e relida antes de contar, o que responde à linha sobre backup. Cada cópia é criptografada com AES-256-GCM com uma chave que pertence só à sua conta, e a nossa página jurídica explica como essas chaves são guardadas. Como uma cópia é feita e restaurada.

O que cada plano cobre e quanto custa está na página de preços.

O que fazer agora

A metade do questionário que trata de criptografia já está respondida. Antes de devolver, escaneie o seu app e veja quais das suas tabelas respondem hoje a um estranho.