A migração das chaves da Supabase para o novo formato sb_publishable e sb_secret é benéfica, mas traz perigos em apps gerados com IA como o Lovable, sobretudo o risco de confundir as duas chaves. A sb_publishable substitui a chave anon e pode ser exposta no cliente, desde que a Row Level Security esteja ativa. A sb_secret substitui a service_role, ignora a RLS e nunca deve aparecer no cliente. O maior perigo durante a migração é colocar a sb_secret onde deveria estar a sb_publishable, ou migrar a chave sem ativar a RLS. Comece confirmando qual chave está no cliente e se a RLS protege suas tabelas.
Resposta rápida
A migração troca as chaves antigas (anon e service_role) pelo novo formato (sb_publishable e sb_secret), e o risco principal é usar a chave errada no lugar errado. Segundo a documentação de chaves da Supabase, a sb_publishable é pública e destinada ao cliente, enquanto a sb_secret ignora a RLS e deve ficar apenas no servidor. Em apps criados com IA, o código gerado pode inserir a chave errada ou omitir a Row Level Security. Primeiro, confirme que apenas a sb_publishable está no cliente e que a RLS protege cada tabela. Se a sb_secret vazou, rotacione-a imediatamente.
O que significa a migração para sb_publishable?
A migração significa substituir as chaves de API antigas da Supabase pelo novo formato, no qual a sb_publishable ocupa o lugar da antiga chave anon e a sb_secret ocupa o lugar da service_role. As chaves antigas serão descontinuadas, por isso a Supabase recomenda adotar o novo formato. Do ponto de vista de segurança, o papel de cada chave permanece o mesmo: uma é pública e a outra é secreta.
O importante é entender que a migração não muda as regras de segurança, apenas o nome e o formato das chaves. A sb_publishable continua sendo segura para o cliente somente se a RLS estiver ativa, exatamente como a anon. A sb_secret continua sendo perigosa e exclusiva do servidor, como a service_role. Portanto, migrar corretamente é, acima de tudo, colocar cada nova chave no mesmo tipo de lugar em que a chave antiga correspondente deveria estar.
Por que a migração é perigosa em apps com IA?
O perigo em apps gerados com IA vem da facilidade de trocar as chaves sem entender o papel de cada uma. Ferramentas como o Lovable geram código que funciona rapidamente, mas nem sempre distinguem uma chave pública de uma secreta, de modo que, durante a migração, o assistente pode inserir a sb_secret no cliente ou deixar uma chave secreta no repositório. Como a sb_secret ignora a RLS, essa troca expõe todos os dados.
Há ainda um risco silencioso: migrar a chave sem verificar a RLS. Se o app foi criado sem Row Level Security, trocar a anon pela sb_publishable não corrige nada, porque a proteção real sempre esteve na RLS, e não no nome da chave. Assim, a migração pode dar uma falsa sensação de modernização e segurança enquanto o problema de fundo, a ausência de RLS, permanece intacto. Tratar o código gerado como algo a revisar, e não a confiar, é essencial.
sb_publishable vs sb_secret: a diferença crítica
A diferença entre as duas chaves é a coisa mais importante a compreender na migração. A sb_publishable é pública por definição: ela concede apenas o papel anônimo ou autenticado, cujo acesso é limitado pelas suas políticas de RLS, e por isso pode ficar no código do cliente. É o equivalente direto da antiga chave anon.
A sb_secret é o oposto: ela ignora a RLS por completo e tem acesso total aos dados, o que a torna equivalente à service_role. Por isso, ela deve viver somente no servidor e jamais aparecer no cliente, em um repositório ou no pacote de um app. Confundir as duas é o erro mais grave da migração: expor a sb_publishable é normal e esperado, mas expor a sb_secret é um comprometimento total, porque ignora todas as políticas que você escreveu.
O que fazer primeiro
O primeiro passo é identificar qual chave está no cliente e garantir que seja a sb_publishable, nunca a sb_secret. Abra o código do frontend ou do app e confirme que a chave presente é a pública. Se encontrar uma sb_secret ou uma antiga service_role no cliente, trate isso como uma emergência: remova-a e rotacione-a de imediato, pois ela pode já ter sido copiada.
Em seguida, confirme que a Row Level Security está ativa nas tabelas que o cliente acessa. Como a sb_publishable só é segura com a RLS, verificar as políticas é tão importante quanto verificar a chave. Comece por esses dois pontos, a chave certa no cliente e a RLS ativa, porque juntos determinam se a sua migração é realmente segura ou apenas parece moderna.
O que verificar em seguida
Depois dos primeiros passos, verifique a cobertura completa. Percorra todas as tabelas e confirme que a RLS está ativada em cada uma que o cliente pode alcançar, e que as políticas restringem cada papel ao que ele deveria acessar. Teste consultando como o papel anônimo, usando a chave pública, para confirmar que não consegue ler nem alterar dados que deveriam estar protegidos.
Verifique também o servidor e o histórico. Garanta que a sb_secret exista apenas em variáveis de ambiente do servidor e nunca tenha sido enviada a um repositório. Se ela apareceu em qualquer lugar acessível, rotacione-a e avalie o que ficou exposto. Essa verificação de cobertura é o que transforma uma migração aparentemente concluída em uma migração de fato segura.
A RLS continua sendo essencial
A Row Level Security continua sendo o verdadeiro controle de segurança, antes e depois da migração. Nenhuma mudança de formato de chave substitui a RLS, porque é ela que decide o que o papel anônimo pode ler ou escrever. Uma sb_publishable exposta sem RLS é tão perigosa quanto uma chave anon exposta sem RLS: qualquer pessoa com a chave pública alcança todos os dados.
Por isso, ative a RLS em todas as tabelas acessíveis pelo cliente e escreva políticas de menor privilégio, permitindo, por exemplo, que cada usuário acesse apenas suas próprias linhas. Ative a RLS primeiro, pois uma tabela sem ela fica aberta independentemente de qualquer política. Teste como o papel anônimo para confirmar que as restrições realmente se aplicam, transformando uma suposição de segurança em um fato verificado.
Quando escalar ou rotacionar
A escalada aqui significa rotacionar chaves e avaliar a exposição, e o momento de agir é imediato quando uma chave secreta aparece onde não deveria. Se a sb_secret, ou a antiga service_role, foi para o cliente, um repositório ou o pacote de um app, considere-a comprometida e rotacione-a sem demora, gerando uma nova e removendo a exposta. Rotacionar é o passo que realmente protege, porque apagar o arquivo depois não desfaz uma exposição já ocorrida.
Já a exposição da sb_publishable não é uma emergência, desde que a RLS esteja correta, pois ela foi feita para ser pública. Portanto, priorize a rotação da chave secreta e a verificação da RLS. Avalie quais dados estiveram acessíveis e por quanto tempo, para saber se há também uma obrigação de comunicação. Só então a migração pode ser considerada realmente encerrada.
Chaves e RLS comparadas
Ver as chaves lado a lado esclarece onde cada uma pertence. A tabela a seguir resume o papel de cada chave e onde ela deve ficar.
| Chave | Pode ser exposta? | Onde usar |
|---|---|---|
| sb_publishable | Sim, com RLS ativa | No cliente e no frontend |
| sb_secret | Nunca | Apenas no servidor |
| Legada anon | Descontinuada, migrar | Equivalente à sb_publishable |
| Legada service_role | Nunca no cliente | Migrar, apenas no servidor |
Leia a tabela como uma regra de colocação. A chave pública e sua equivalente antiga vão no cliente, com RLS; a chave secreta e sua equivalente antiga ficam apenas no servidor. Uma chave secreta no cliente está sempre errada, seja no formato novo ou no antigo.
Lista de verificação
Uma verificação curta confirma que a migração foi segura. A lista a seguir cobre os pontos essenciais.
| Verificação | Ação | Feito |
|---|---|---|
| Tipo de chave | Confirmar que apenas a sb_publishable está no cliente | [ ] |
| Segredo no cliente | Garantir que a sb_secret não vazou | [ ] |
| RLS ativa | Ativar a Row Level Security em todas as tabelas | [ ] |
| Testar como anônimo | Confirmar que o acesso está restrito | [ ] |
| Rotacionar | Rotacionar qualquer chave secreta exposta | [ ] |
As duas verificações mais importantes são garantir que a sb_secret nunca esteja no cliente e que a RLS esteja ativa e testada. Juntas, elas determinam se a migração tornou o app seguro ou apenas mudou o nome das chaves.
Verifique com um scanner
Corrigir a RLS protege o back-end, mas vale verificar também o app que você distribui, pois o mesmo padrão de criação rápida que troca chaves sem cuidado pode embarcar uma chave secreta na compilação. Esse é o caso perigoso, e não a chave pública, e é fácil passar despercebido em um pacote grande.
Um scanner como o PTKD.com analisa a compilação do seu app e retorna resultados ordenados por gravidade e associados ao OWASP MASVS, incluindo segredos embutidos no binário, para que você confirme que nenhuma chave secreta foi distribuída. Para deixar claro o limite: o PTKD não configura a sua RLS nem migra as suas chaves. Ele verifica o artefato distribuído, complementando o trabalho de RLS que realmente protege os dados.
O que levar em conta
- A migração troca as chaves antigas pelo novo formato, mas não muda as regras: a sb_publishable é pública e a sb_secret é secreta.
- Em apps com IA como o Lovable, o maior risco é colocar a sb_secret no cliente ou migrar sem ativar a Row Level Security.
- A sb_publishable só é segura com a RLS ativa; trocar a chave não corrige a ausência de RLS.
- Primeiro, confirme que apenas a sb_publishable está no cliente e que a RLS protege cada tabela; rotacione qualquer chave secreta exposta.
- Verifique a compilação com o PTKD.com para garantir que nenhuma chave secreta tenha sido embarcada no app.
