# Chave de API secreta no Expo: o que proteger

> Chave pública do Supabase, segredo de servidor, variáveis do Expo: saiba o que pode ir no seu app iPhone e teste os acessos com duas contas.

Página original: [Chave de API secreta no Expo: o que proteger](https://devoria.fr/pt-br/blog/chave-api-secreta-expo-o-que-proteger)
Autor: [Mehdi Azizi](https://devoria.fr/pt-br/mehdi-azizi)
Publicação: 2026-09-29
Última revisão do conteúdo: 2026-10-09


## 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](https://docs.expo.dev/guides/environment-variables/).

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](https://supabase.com/docs/guides/getting-started/api-keys).

## 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](https://supabase.com/docs/guides/database/postgres/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](https://devoria.fr/pt-br/resources) 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](https://devoria.fr/pt-br/blog/guideline-5-1-2-ia-terceiros-att-compartilhamento-dados), 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](https://devoria.fr/pt-br/blog/criar-app-claude-code-tutorial-iphone) 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](https://devoria.fr/pt-br/expertise/criar-um-app-para-iphone) coloca essa etapa dentro do projeto completo. Para avançar na ordem certa, o [iOS Kit](https://devoria.fr/pt-br/kits/ios) 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](https://devoria.fr/pt-br/diagnostic) 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.


## Seu projeto

[iOS Kit](https://devoria.fr/pt-br/kits/ios): Crie seu app de iPhone com Claude Code: o código inicial dos meus apps, as skills que verificam o trabalho dele e os kits Apple Review, App Store Screenshots e ASO. 129,99 €.