Reeve Noções de segurança
O que é Supabase? O banco de dados que seu builder escolheu
O que é Supabase: o banco de dados, o login e o armazenamento de arquivos do seu app. O Supabase cuida dos servidores; as regras das suas linhas são suas.
Em resumo
- O que é Supabase? É onde seu app guarda tudo o que precisa lembrar: seus usuários e as senhas deles, as linhas por trás de cada lista e os arquivos que as pessoas sobem.
- Seu builder quase certamente escolheu por você enquanto criava o projeto, e é por isso que ninguém nunca te mostrou o que tem lá dentro.
- O Supabase cuida das máquinas. As regras sobre quem pode ler quais linhas são suas, e numa tabela criada com SQL elas começam desligadas.
Seu app funciona. Em algum lugar das configurações dele, num e-mail sobre uma cobrança ou no meio de uma mensagem do Lovable, está a palavra Supabase. Cedo ou tarde você precisa descobrir o que é isso, e o motivo raramente é curiosidade: um scan citou seu projeto do Supabase, um desenvolvedor perguntou em que plano você está, ou seu app parou de salvar coisas e a resposta está ali dentro.
Então: o que é Supabase. Toda outra explicação responde isso como uma escolha entre ferramentas, que é a pergunta que um desenvolvedor faz antes de começar um projeto. Você nunca fez essa escolha. Seu builder fez nos segundos que levou para criar o projeto, e é por isso que ninguém nunca te guiou pela coisa que agora guarda todos os dados dos seus usuários.
Esta é a versão para quem já tem um.
O que é Supabase, em uma frase?
É onde seu app guarda tudo o que precisa lembrar.
Seus usuários e as senhas deles. As linhas por trás de cada lista que seu app mostra. As imagens e documentos que as pessoas sobem. Quando alguém se cadastra às duas da manhã, esse registro cai no seu projeto do Supabase e continua lá depois que a aba do navegador fecha.
Por baixo está o Postgres, um banco de dados em uso em produção desde os anos noventa e que não vai te surpreender. O que o Supabase acrescenta é tudo em volta: um sistema de login, um lugar para arquivos e um jeito de o seu app pedir dados direto do navegador sem que você escreva um servidor.
É nesse último que as suas próprias decisões começam.
As quatro peças que você realmente tem
Quatro, e seu app provavelmente está usando pelo menos duas.
- O banco de dados. Tabelas de linhas: seus usuários, seus pedidos, suas publicações. A parte que as pessoas querem dizer quando falam "Supabase".
- Auth. Cadastro, login, redefinição de senha. Se seu app tem contas, elas moram aqui.
- Storage. Arquivos enviados, em buckets com nome. Fotos de perfil, anexos, exportações.
- Edge functions. Pedacinhos de código que rodam nos servidores do Supabase em vez de no navegador do seu visitante. Talvez seu app não tenha nenhuma, e mesmo assim há um bom motivo para se interessar, mais abaixo.
Seu painel lista mais do que essas quatro. Deixe o resto quieto até que o que você está construindo precise.
De que o Supabase cuida e o que é meu?
O Supabase cuida das máquinas. Você cuida das regras.
A linha fica mais acima do que quase todo mundo imagina. Pense no projeto como um imóvel que você aluga. O proprietário mantém o prédio, a energia e a porta da rua. O que você guarda lá dentro, e quem você deixa entrar, nunca foi decisão dele.
| O que o Supabase opera | O que é seu |
|---|---|
| Os servidores, a versão do Postgres e as atualizações | Quais linhas cada visitante pode ler |
| Backups diários do seu banco nos planos pagos, guardados por uma semana | Se existe uma cópia em algum lugar que o seu próprio projeto não alcança |
| Criptografar seus dados nos discos deles e no caminho até seu app | Quem tem as suas chaves e qual delas está no seu app |
| Manter o sistema de login funcionando | Quais arquivos de um bucket qualquer pessoa consegue listar |
Nada da coluna da esquerda falha em silêncio: se o Supabase cair, você fica sabendo pelos seus usuários em poucos minutos. A coluna da direita é onde as coisas dão errado sem barulho nenhum, porque nada quebra. Seu app continua funcionando exatamente como ontem.
Meus dados no Supabase são privados por padrão?
Depende de como cada tabela foi criada, e o jeito como um builder cria tabelas é o jeito que as deixa abertas.
A documentação do próprio Supabase é direta sobre isso. Ela diz que o Table Editor liga o Row Level Security para você quando você cria uma tabela no Dashboard, e que quando você cria uma tabela com SQL quem liga é você. Row Level Security é o ajuste por tabela que decide quais linhas um visitante pode ler. Seu builder escreve SQL, então uma tabela criada por ele chega com esse ajuste desligado.
A frase seguinte da mesma página diz o que isso deixa para trás: uma tabela no
schema public é alcançável pela Data API, e enquanto você não ligar o Row
Level Security e escrever uma política, qualquer pessoa com a chave publishable
do seu projeto consegue ler e escrever todas as linhas dela. Essa chave está no
seu app, onde ela deve estar, e qualquer um consegue lê-la da página.
Então a fechadura de cada tabela é o que você precisa ir olhar, e ela é por tabela em vez de por projeto. Como ligar, e o que é uma política, é o passo a passo. A gente também contou quantas vezes ela falta: 2.096 dos 3.680 apps cujo banco Supabase nos respondeu tinham pelo menos uma tabela entregando as linhas para um estranho.
Se você prefere ver de fora em vez de percorrer uma lista de tabelas, nosso scan gratuito faz ao seu projeto a pergunta que o navegador de um estranho faria e mostra o que voltou. Leva uns 20 segundos e não precisa de conta: escaneie seu app de graça.
Onde estão suas chaves e qual delas é pública
Sua página de configurações de API tem valores de dois tipos, e só um tipo pertence ao seu app.
Uma chave que começa com sb_publishable_, chamada anon num projeto mais
antigo, é feita para ser pública e sozinha não faz nada além de dizer a que
projeto um pedido pertence. Uma chave que começa com sb_secret_, chamada
service_role num projeto mais antigo, passa direto por cima de todas as regras
que você criar. O Supabase diz isso com todas as letras: uma chave secreta
ignora o Row Level Security, então ela tem que ficar no servidor. Esse é também
o bom motivo para se interessar por edge functions, porque uma function é onde o
trabalho que precisa de uma chave secreta pode acontecer sem a chave chegar
perto de um navegador.
Onde fica essa página e o que cada valor nela faz cobre os lugares, e quais chaves são seguras no frontend cobre como distinguir duas chaves quase idênticas.
Como continuar sendo seu depois de publicar
O que você encontrar hoje descreve o app de hoje. A próxima tabela que seu builder criar chega com o mesmo padrão da anterior, e ninguém te manda uma mensagem sobre isso.
O Reeve Monitor refaz as perguntas deste artigo, com hora marcada:
- as nove verificações a cada hora, em até três apps
- se o app está no ar, a cada 60 segundos
- uma mensagem quando um resultado muda, para que uma tabela que abriu ontem à noite chegue a você antes de chegar a um estranho
- um relatório mensal do que foi visto
O Reeve Care ainda guarda uma cópia do seu banco de dados Supabase. É a segunda linha da coluna da direita lá em cima, feita para você.
- uma cópia criptografada do seu banco Supabase toda noite, guardada onde seu projeto não alcança
- cada cópia verificada antes de valer, contando as linhas de cada tabela
- uma restauração em um clique quando você precisar
- seus arquivos enviados também, assim que você conectar uma credencial de Storage
- tudo o que o Monitor faz
Uma tabela que um estranho consegue ler é uma coisa que uma verificação acha. Uma migração que rodou ao contrário, ou um agente com acesso ao seu banco, esvazia a tabela, e é assim que isso parece por dentro.
O que verificar uma vez, hoje
O que fazer
- Entre no Supabase e abra o seu próprio projeto. A conta é sua mesmo que seu builder a tenha criado, e é no painel que está cada uma das respostas abaixo.
- Leia a fechadura de cada tabela em Authentication → Policies. Uma tabela com Row Level Security desligado entrega as linhas para qualquer um que tenha a chave que já está no seu app, e uma política que libera todo mundo conta como desligada.
- Abra Settings → API Keys e descubra quais dos seus valores são publishable e quais são secret. Se alguma secreta já esteve no seu app, troque-a no Supabase antes de tirar do código.
- Olhe seus buckets de storage. Um bucket marcado como público lista todos os arquivos dele para quem perguntar, inclusive os que seu app nunca mostra.
- Guarde uma cópia do banco em algum lugar que o seu projeto não alcança, porque nada da lista acima traz de volta uma tabela apagada.
Comece pelas fechaduras das tabelas, porque é o único item desta lista que um estranho já pode estar usando. Se você prefere percorrer tudo como uma lista, o checklist de segurança em 10 minutos cobre isso e os outros ajustes que valem a leitura num app recém-publicado. O Supabase é seguro? pega a outra pergunta com que as pessoas chegam, que é se tudo isso foi uma boa ideia.
Perguntas frequentes
O que é Supabase em termos simples?
É onde seu app guarda tudo o que precisa lembrar, em servidores que outra pessoa mantém. Seus usuários e as senhas deles, as linhas por trás de cada lista que seu app mostra e os arquivos que as pessoas sobem ficam todos no seu projeto do Supabase. Ele é construído sobre o Postgres, um banco de dados em uso em produção desde os anos noventa, com um sistema de login, armazenamento de arquivos e um jeito de o seu app pedir dados direto do navegador montados em volta.
O Supabase é um banco de dados?
Ele contém um, e é mais do que um. O banco é o Postgres e é a parte que as pessoas querem dizer quando falam Supabase. Em volta dele ficam outros três serviços que seu app talvez esteja usando: Auth para fazer login, Storage para os arquivos enviados e Edge Functions para código que roda nos servidores do Supabase em vez de no navegador do seu visitante. Seu painel lista mais do que esses quatro, e você pode deixar o resto quieto até precisar de alguma coisa.
Foi o builder do meu app que escolheu o Supabase?
Quase certamente, sim. Lovable, Bolt, v0, Cursor, Replit e Windsurf recorrem todos a um Postgres hospedado assim que seu app precisa lembrar de alguma coisa, e o Supabase é a resposta mais comum. Talvez você tenha clicado num botão escrito conectar um banco de dados, ou talvez seu builder tenha criado o projeto sem perguntar. De um jeito ou de outro a conta é sua e você consegue entrar nela, e é a primeira coisa que vale a pena fazer.
Quais partes da segurança do Supabase são tarefa minha?
O Supabase cuida dos servidores, da versão do Postgres, das atualizações, da criptografia nos discos deles e do próprio sistema de login. Suas são as regras: quais linhas cada visitante pode ler, quais arquivos de um bucket são públicos, quem tem as suas chaves e qual delas está no seu app, e se existe uma cópia dos seus dados em algum lugar que o seu projeto não alcança. Nada da primeira lista falha em silêncio. Tudo da segunda pode ficar errado por meses enquanto seu app funciona perfeitamente.
Meus dados no Supabase são privados por padrão?
Depende de como cada tabela foi criada. A documentação do Supabase diz que o Table Editor liga o Row Level Security para você quando você cria uma tabela no Dashboard, e que quando você cria uma tabela com SQL quem liga é você. Um builder escreve SQL, então as tabelas que ele criou para você chegam com esse ajuste desligado. Enquanto ele estiver desligado e não houver uma política escrita, o Supabase diz que qualquer pessoa com a sua chave publishable consegue ler e escrever todas as linhas daquela tabela, e essa chave está no seu app, onde qualquer um consegue ler.