Busque em todas as páginas da documentação
Manuseio de segredos, armazenamento seguro, segurança de transporte e decisões de fixação de certificados para aplicativos Expo no SDK 57. Clientes móveis são ambientes não confiáveis - assuma que atacantes podem extrair valores empacotados, interceptar tráfego em dispositivos comprometidos e reproduzir tokens. Estas regras definem o nível mínimo antes da submissão para a loja.
expo config --type public e fluxos de logout são falhas comuns de auditoria.Nunca coloque segredos em EXPO_PUBLIC_* ou extra: Ambos são incorporados ao pacote do cliente - atacantes os extraem do IPA/APK ou bytecode Hermes.
EAS Secrets para valores em tempo de compilação e CI: eas secret:create e variáveis com escopo de ambiente - não Slack, não .env.production commitado.
eas env:pull --environment development - .env.local permanece ignorado pelo git.eas update --environment production usa variáveis de ambiente EAS (SDK 55+) - .env local é ignorado nos executores de atualização.Audite a configuração pública antes de cada lançamento: npx expo config --type public - confirme que nenhum URL de staging, nomes de host internos ou chaves de depuração foram enviados para o perfil de produção.
.env.example documenta chaves, não valores: Liste as variáveis EXPO_PUBLIC_* e APP_ENV necessárias com valores de placeholder - integração sem vazar segredos de produção.
Sem segredos em logs de crash ou breadcrumbs de análise: Sentry e utilitários de log devem limpar tokens, e-mails e fragmentos de PAN antes do upload.
Authorization em breadcrumbs de rede.Chaves de SDK de terceiros revisadas para exposição no cliente: Chaves de mapas, análises e atribuição no pacote são consideradas públicas - restrinja por ID do pacote e plataforma no painel do fornecedor.
Tokens de atualização e acesso no expo-secure-store: Keystore com suporte de hardware em dispositivos compatíveis - não AsyncStorage, MMKV sem criptografia ou arquivos expo-file-system simples.
npx expo install expo-secure-store.AsyncStorage apenas para preferências não sensíveis: Tema, última aba, estado da UI de rascunho - nunca artefatos de autenticação ou caches de PII.
grep para AsyncStorage.setItem com chaves semelhantes a tokens na revisão de PR.Limpar armazenamento seguro ao sair: SecureStore.deleteItemAsync para todas as chaves de autenticação - emparelhado com a redefinição da pilha de navegação (veja Regras de Navegação e Roteamento).
Tokens de acesso de curta duração com rotação de atualização: Clientes móveis devem atualizar proativamente - lidar com 401 com uma única tentativa, não loops infinitos.
AppState foreground se o token estiver perto da expiração.Gateway biométrico para ações sensíveis, não substituição de armazenamento: expo-local-authentication desbloqueia a UI ou confirma transações - não substitui o armazenamento seguro do enclave para tokens.
Criptografar caches offline que contêm PII: Se MMKV ou SQLite armazenarem dados de saúde ou financeiros do usuário, use criptografia ou minimização do lado do servidor - MMKV padrão é rápido, não confidencial.
Somente HTTPS para chamadas de API de produção: Rejeitar exceções de texto claro na configuração de produção app.config - android.usesCleartextTraffic é apenas para compilações de desenvolvimento local.
http://localhost no perfil de desenvolvimento com APP_ENV=development.http:// em src/ fora de __tests__.A fixação de certificados é uma decisão explícita do produto: Padrão para validação de certificado do sistema no SDK 57 - a fixação quebra proxies corporativos, complica a rotação e requer módulos nativos.
Se fixar, planeje a rotação antes da implementação: Fixe hashes SPKI com pins de backup - atualizações de loja demoram semanas; pins expirados travam o aplicativo.
Validar TLS na camada do cliente de API: Wrapper fetch central rejeita não-HTTPS em compilações de produção - um ponto de estrangulamento para cabeçalhos e anexos de autenticação.
api/client.ts anexa o bearer do armazenamento seguro; recursos nunca chamam fetch bruto para URLs arbitrários.fetch(process.env.EXPO_PUBLIC_API_URL + path) disperso sem validação.Não desative a verificação SSL em produção: rejectUnauthorized: false e agentes fetch personalizados são apenas para depuração - grep CI os bloqueia em main.
OAuth e deep links usam parâmetros PKCE e state: expo-auth-session com redirecionamento seguro - valide state no retorno; nunca incorpore segredos do cliente em fluxos OAuth móveis.
app.config - sem URIs de redirecionamento wildcard no console do provedor.Detecção de jailbreak/root é baseada em política, não em teatro de segurança: Se exigido pela conformidade, use um SDK mantido e documente limitações de bypass - não afirme "inviolável".
Política de captura de tela e gravação de tela para telas sensíveis: Flag segura UITextField do iOS ou overlay para entrada de CVV - equilibre UX com orientações PCI e HIPAA.
FLAG_SECURE via plugin de configuração quando mandatório.Permissões são mínimas e justificadas: Solicite câmera, localização e contatos apenas quando o recurso estiver ativo - a revisão do iOS/Android e a confiança do usuário dependem disso.
app.config e locales/ localizados.Auditoria de dependências antes da submissão para a loja: npm audit, expo-doctor e revisão de manifestos de privacidade de SDK nativos (Rótulos de Nutrição de Privacidade da Apple).
Flags de recursos não ignoram autorização do servidor: Flags do cliente ocultam a UI - o servidor deve impor os direitos em cada mutação.
Runbook de incidentes para comprometimento de token e chave: Documente quem rotaciona EAS Secrets, revoga clientes OAuth e força o logout - líderes móveis conhecem os passos antes de um incidente.
Somente se a chave for projetada para exposição no cliente (por exemplo, chave de cliente do Google Maps restrita por ID do pacote). Segredos de servidor, chaves secretas do Stripe e tokens de administrador nunca devem estar em EXPO_PUBLIC_*.
Use expo-secure-store por padrão para tokens no SDK 57. MMKV com criptografia é uma opção para dados estruturados maiores - ainda requer um ADR e uma história de gerenciamento de chaves; secure store é mais simples para artefatos de autenticação.
A maioria dos aplicativos não deve fixar inicialmente - TLS do sistema mais ciclo de vida adequado de certificados no servidor é suficiente. Fixe quando o modelo de ameaça e as operações de segurança puderem gerenciar a rotação; documente em um ADR.
EAS Secrets e variáveis de ambiente são injetados no tempo de compilação/atualização nos workers EAS - eles não significam automaticamente que são seguros para pacotes do cliente. Apenas valores não sensíveis devem chegar ao JS via extra ou env público. Segredos verdadeiros permanecem no lado do servidor.
Expo Go usa o ID do pacote do Expo - o redirecionamento OAuth e algumas restrições do SDK diferem da produção. Teste a autenticação em dev-client ou builds de preview com seu ID de pacote real antes do lançamento.
Execute npx expo config --type public com variáveis de ambiente de produção e inspecione a saída. Adicione grep CI para padrões como sk_live, BEGIN PRIVATE KEY e nomes de host internos.
Chaves de autenticação do armazenamento seguro, estado de sessão em memória, caches de consulta com PII e pilha de navegação para autenticação - nessa ordem. Verifique com teste automatizado ou smoke test do Maestro.
OTA pode remover uma chave vazada de novos pacotes - mas instalações existentes podem reter pacotes antigos até a atualização. Rotacione o segredo comprometido imediatamente no servidor; trate OTA como correção de distribuição, não rotação.
Somente quando a política de conformidade ou de fraude exigir - entenda que é contornável. Documente as limitações em ADR; não confie nele para autorização principal.
Curto (minutos a poucas dezenas de minutos) com rotação de atualização - aplicativos móveis são instalações de longa duração. Coordene a lógica de atualização com manipuladores de AppState em segundo plano.
Não - trate parâmetros de URL como entrada não confiável. Nunca conceda privilégios de ?role=admin. Valide a sessão no lado do servidor.
Evite armazenar em cache imagens sensíveis em disco sem criptografia. Use URLs assinados expirados e limpe caches ao sair.
Não - segredos ainda são enviados em pacotes, as APIs de armazenamento seguro não mudaram. Mantenha o mesmo checklist no RN 0.86.
Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última atualização: 9 de jul. de 2026