Separar chaves públicas e secretas

Identifique a finalidade

A URL do projeto e a chave publishable podem integrar o cliente web. O acesso aos registros continua dependendo dos grants, da sessão e das políticas RLS. A chave identifica a aplicação, enquanto o token de sessão representa o usuário autenticado.

Chaves secret pertencem a serviços confiáveis. As chaves legadas anon e service_role ainda aparecem em projetos e tutoriais. Consulte a documentação da instalação antes de trocar formatos, pois uma integração antiga pode aceitar somente o formato legado.

Revise a aplicação web

Procure variáveis com prefixos públicos, como VITE_ e PUBLIC_. Elas podem ser incorporadas ao JavaScript entregue ao visitante. Coloque somente a URL e a chave pública nesses campos. O nome de um arquivo .env não impede que o bundler publique os valores destinados ao cliente.

Inspecione o bundle de produção e as requisições do navegador. Nenhuma chave secret ou service_role deve aparecer. Não cole credenciais em issues, prompts, screenshots ou exemplos de documentação.

Limite as operações do servidor

Quando uma rotina precisar de privilégios elevados, mantenha-a no servidor e valide a identidade e a autorização de cada chamada. Separe o cliente administrativo do cliente que representa a sessão do usuário. Uma consulta privilegiada pode ultrapassar a proteção esperada por uma aplicação que depende de RLS.

Use um gerenciador de segredos no ambiente de execução. Registre os nomes das variáveis necessárias sem registrar seus valores. Confira também logs de erro: corpos de requisição e cabeçalhos podem carregar credenciais.

Se uma chave secreta aparecer

Revogue ou substitua a credencial no projeto, atualize os serviços que dependem dela e confira os acessos recentes. Remover a linha do último commit não invalida uma chave que já foi copiada. Faça a rotação conforme o tipo de chave e o ambiente, mantendo uma forma de verificar se cada serviço voltou a funcionar.