Chave de API secreta no Expo: o que proteger

Uma variável de ambiente não é necessariamente um segredo

Em um app Expo, uma variável com o prefixo EXPO_PUBLIC_ é feita para o código do app. Ela não deve conter um segredo de servidor. O Expo explica que esses valores são embutidos no JavaScript compilado e podem ser lidos pelos usuários do app. Então, mover uma chave para um arquivo .env não basta para protegê-la. Fonte: variáveis de ambiente do Expo.

Antes de pedir para uma IA "conectar a API", classifique o que você está entregando para ela: um endereço de serviço, uma chave feita para ser pública ou uma chave que autoriza ações privilegiadas. Essa classificação define onde o código deve rodar.

A tabela a seguir é um guia de arquitetura, não uma auditoria do seu app.

Elemento	Onde colocar	O que verificar
Endereço público do backend	Configuração do app	Ele aponta para o ambiente certo.
Chave Supabase publishable, ou a antiga chave anon	No app, se as permissões estiverem bem configuradas	As regras de dados bloqueiam de verdade o acesso à conta de outro usuário.
Chave Supabase secret ou service_role	Só no servidor	Ela não aparece nem no bundle mobile, nem nos logs acessíveis ao cliente.
Chave secreta de um provedor de IA	Só no servidor	O app chama o seu servidor, que verifica o usuário e os limites antes de chamar o provedor.

O Supabase separa as chaves feitas para clientes das chaves secretas destinadas a ambientes confiáveis. Uma chave pública identifica o projeto; ela não substitui as permissões sobre os dados. Fonte: chaves de API do Supabase.

Exemplo: um app fictício de diário de leitura

Imagine um app em que a Léa e o Sami registram seus livros e suas anotações privadas. Esse exemplo serve para preparar os testes; ele não descreve resultados obtidos em um app da Devoria.

O fluxo normal parece certo: a Léa faz login e vê as anotações dela. Mas isso ainda não responde à pergunta importante: o servidor recusa um pedido da Léa que mira uma anotação do Sami?

Um filtro na interface, como "mostrar as anotações do usuário logado", melhora a exibição. A autorização também precisa ser aplicada no lado dos dados. No Supabase, as regras de Row Level Security permitem restringir as linhas acessíveis de acordo com a sessão. O Supabase recomenda ativá-las nas tabelas expostas pela API e explica as políticas de leitura e escrita. Fonte: Row Level Security.

No seu próprio projeto de teste, associe cada anotação ao seu dono e defina separadamente quem pode lê-la, criá-la, editá-la e excluí-la. Verifique também os arquivos: proteger uma linha do banco de dados não prova que uma imagem é privada.

O roteiro de testes para rodar com duas contas

Prepare duas contas que você controla, um livro diferente em cada uma e uma anotação curta fácil de reconhecer. Use dados fictícios em um ambiente de teste autorizado.

1. Ler a própria anotação. A conta A encontra a anotação A.
2. Ler a anotação de B a partir de A. O pedido não revela o conteúdo privado dela.
3. Editar a anotação de B a partir de A. O servidor recusa; a anotação B continua igual.
4. Criar em nome de B a partir de A. O servidor recusa essa atribuição.
5. Ler sem sessão. Nenhum conteúdo privado é retornado.
6. Abrir o arquivo privado de B a partir de A. O arquivo não fica acessível.

Anote o resultado real, a versão testada e o eventual erro. "As regras estão ativadas" não é um resultado de teste. O roteiro de testes disponível nos recursos pode servir de base para guardar essas provas.

Passe as chamadas pagas pelo seu servidor

Para uma função que resume um livro com uma API de IA, o fluxo pode ser: app → seu servidor → provedor → seu servidor → app. A chave secreta fica no servidor. Essa arquitetura sozinha não basta: o acesso ao servidor também precisa ser controlado.

No exemplo fictício, o servidor precisa, entre outras coisas, verificar a sessão, verificar se o livro pertence à pessoa, limitar pedidos repetidos e devolver um erro compreensível se o provedor não responder. Não é o cliente que decide sozinho que um usuário tem acesso pago.

Prepare quatro testes: usuário não logado, livro de outra conta, limite atingido e provedor indisponível. O último permite verificar se o app sai do estado de carregamento sem perder o que foi digitado.

O que você pode pedir para o seu assistente de código

Aqui vai um prompt de revisão para adaptar ao seu repositório, sem colar nele os seus valores secretos:

Liste as variáveis usadas pelo código mobile e pelo servidor, mostrando apenas os nomes. Identifique as chamadas privilegiadas presentes no lado do cliente. Para os dados privados, descreva os controles de leitura e escrita e depois proponha um roteiro de testes com duas contas de teste. Não faça nenhuma rotação de chave nem alteração em produção sem validação.

Leia a resposta junto com o código correspondente. Um assistente pode encontrar uma inconsistência; a resposta dele não substitui rodar os testes. O guia criar um app com Claude Code explica como dividir esse trabalho.

Antes de continuar o seu app

Você precisa conseguir explicar três coisas de forma simples: quais valores são públicos, quais operações passam pelo servidor e quais testes mostram que uma conta não vê os dados de outra. Se algum desses pontos ainda estiver confuso, esclareça antes de adicionar funções.

A página criar um app para iPhone coloca essa etapa dentro do projeto completo. Para avançar na ordem certa, o iOS Kit oferece um percurso em quatro etapas e um código inicial que já inclui as contas e a IA. Se você não sabe mais por qual etapa retomar, o diagnóstico gratuito coloca o seu projeto em ordem e te envia o meu checklist anti-rejeição da Apple.

Perguntas frequentes

Onde colocar uma chave de API secreta em um app Expo?

No seu servidor, nunca no app. A chave Supabase secret ou service_role, assim como a chave secreta de um provedor de IA, deve ficar só no servidor. O app chama o seu servidor, que verifica o usuário e os limites antes de chamar o provedor. Confira se nenhuma dessas chaves aparece no bundle mobile nem nos logs acessíveis ao cliente.

Um arquivo .env protege minha chave de API no Expo?

Não sozinho. Uma variável com o prefixo EXPO_PUBLIC_ é feita para o código do app e não deve conter um segredo de servidor. O Expo explica que esses valores são embutidos no JavaScript compilado e podem ser lidos pelos usuários do app. Então, mover uma chave para um arquivo .env não basta para protegê-la.

Qual a diferença entre uma chave de API pública e uma chave secreta?

Uma chave pública é feita para ir dentro do app: ela identifica o projeto, mas não substitui as permissões sobre os dados. Uma chave secreta autoriza ações privilegiadas e fica reservada a ambientes confiáveis. No Supabase, a chave publishable, ou a antiga chave anon, pode ficar no app se as permissões estiverem bem configuradas. As chaves secret e service_role ficam no servidor.

Como chamar uma API de IA em um app Expo sem expor a chave?

Passe a chamada pelo seu servidor: o app chama o servidor, que chama o provedor e depois devolve a resposta para o app. A chave secreta fica no servidor. Ele também precisa verificar a sessão, limitar pedidos repetidos e devolver um erro compreensível se o provedor não responder. Não é o cliente que decide sozinho que um usuário tem acesso pago.

Como verificar que cada usuário só vê os próprios dados?

Prepare duas contas de teste que você controla, com uma anotação fácil de reconhecer em cada uma. A partir da conta A, tente ler, editar e criar em nome da conta B, e depois abrir o arquivo privado de B. Faça também os testes sem sessão: cada pedido deve ser recusado ou não revelar nada. Anote o resultado real, porque "as regras estão ativadas" não é um resultado de teste.

Como pedir para uma IA verificar as chaves do meu app?

Peça para ela listar as variáveis do código mobile e do servidor, mostrando apenas os nomes, sem colar os seus valores secretos. Peça também para identificar as chamadas privilegiadas presentes no lado do cliente e propor um roteiro de testes com duas contas de teste. Proíba qualquer rotação de chave ou alteração em produção sem validação. A resposta dela não substitui rodar os testes.