Busca en todas las páginas de la documentación
Manejo de secretos, almacenamiento seguro, seguridad de transporte y decisiones de fijación de certificados para aplicaciones Expo en SDK 57. Los clientes móviles son entornos no confiables - asume que los atacantes pueden extraer valores agrupados, interceptar tráfico en dispositivos comprometidos y reproducir tokens. Estas reglas definen la barra mínima antes del envío a tienda.
expo config --type public y los flujos de logout son fallas de auditoría comunes.Nunca pongas secretos en EXPO_PUBLIC_* o extra: Ambos se insertan en línea en el bundle del cliente - los atacantes los extraen del IPA/APK o bytecode de Hermes.
EAS Secrets para valores de tiempo de compilación y CI: eas secret:create y variables de alcance de entorno - no Slack, no .env.production comprometido.
eas env:pull --environment development - .env.local se mantiene gitignored.eas update --environment production usa variables de entorno de EAS (SDK 55+) - .env local se ignora en ejecutores de actualización.Audita configuración pública antes de cada lanzamiento: npx expo config --type public - confirma que no hay URLs de staging, nombres de host internos ni claves de depuración enviados al perfil de producción.
.env.example documenta claves, no valores: Lista variables EXPO_PUBLIC_* y APP_ENV requeridas con valores de placeholder - incorporación sin filtrar secretos de prod.
Sin secretos en registros de caída o migas de análisis: Las utilidades de Sentry y logging deben limpiar tokens, correos electrónicos y fragmentos de PAN antes de cargarse.
Authorization en migas de red.Las claves de SDK de terceros se revisan para exposición del cliente: Las claves de mapas, análisis y atribución en el bundle se asumen públicas - restringe por ID de bundle y plataforma en el panel del proveedor.
Tokens de actualización y acceso en expo-secure-store: Almacén de claves respaldado por hardware en dispositivos compatibles - no AsyncStorage, MMKV sin encriptar o archivos simples de expo-file-system.
npx expo install expo-secure-store.AsyncStorage solo para preferencias no sensibles: Tema, última pestaña, estado del UI de borrador - nunca artefactos de autenticación o cachés de PII.
AsyncStorage.setItem con claves tipo token en revisión de PR.Limpia almacenamiento seguro al cerrar sesión: SecureStore.deleteItemAsync para todas las claves de auth - emparejadas con reinicio de pila de navegación (ver Navigation & Routing Rules).
Tokens de acceso de corta vida con rotación de actualización: Los clientes móviles deben actualizarse de forma proactiva - maneja 401 con un único reintento, no bucles infinitos.
AppState si el token se acerca al vencimiento.Puerta biométrica para acciones sensibles, no reemplazo de almacenamiento: expo-local-authentication desbloquea UI o confirma transacciones - no reemplaza almacenamiento de enclave seguro para tokens.
Encripta cachés offline que contienen PII: Si MMKV o SQLite cachean datos de salud o financieros del usuario, usa encriptación o minimización del lado del servidor - MMKV por defecto es rápido, no confidencial.
Solo HTTPS para llamadas API de producción: Rechaza excepciones de texto plano en app.config de producción - android.usesCleartextTraffic es solo para compilaciones de desarrollo local.
http://localhost en perfil de desarrollo con APP_ENV=development.http:// en src/ fuera de __tests__.La fijación de certificados es una decisión explícita de producto: Por defecto a validación de certificado del sistema en SDK 57 - la fijación rompe proxies corporativos, complica la rotación y requiere módulos nativos.
Si fijas, planifica la rotación antes de la implementación: Fija hashes SPKI con pins de respaldo - las actualizaciones almacenadas se retrasan semanas; los pins vencidos rompen la aplicación.
Valida TLS en la capa del cliente API: El wrapper central fetch rechaza no-HTTPS en compilaciones de producción - un único punto de control para encabezados y adición de auth.
api/client.ts adjunta portador desde almacenamiento seguro; las características nunca llaman fetch sin formato a URLs arbitrarias.fetch(process.env.EXPO_PUBLIC_API_URL + path) dispersas sin validación.No desactives verificación SSL en producción: rejectUnauthorized: false y agentes fetch personalizados son solo depuración - grep CI los bloquea en main.
OAuth y enlaces profundos usan PKCE y parámetros de estado: expo-auth-session con redirección segura - valida state en retorno; nunca incrustes secretos de cliente en flujos OAuth móviles.
app.config - sin URIs de redirección comodín en consola del proveedor.La detección de jailbreak/root impulsada por política, no teatro de seguridad: Si es requerida por cumplimiento, usa un SDK mantenido y documenta limitaciones de bypass - no afirmes "imposible de hackear."
Política de captura de pantalla y grabación de pantalla para pantallas sensibles: iOS UITextField bandera segura u overlay para entrada de CVV - equilibra UX con guía PCI e HIPAA.
FLAG_SECURE a través de plugin de config cuando es obligatorio.Permisos son mínimos y justificados: Solicita cámara, ubicación y contactos solo cuando la característica está activa - la revisión de iOS/Android y la confianza del usuario dependen de ello.
app.config y locales/ localizados.Auditoría de dependencias antes del envío a tienda: npm audit, expo-doctor y revisión de manifiestos de privacidad de SDK nativos (Etiquetas de Nutrición de Privacidad de Apple).
Las banderas de características no eluden la autorización del servidor: Las banderas de cliente ocultan UI - el servidor debe aplicar derechos en cada mutación.
Runbook de incidentes para compromiso de token y clave: Documenta quién rota EAS Secrets, revoca clientes OAuth y fuerza logout - los líderes móviles conocen los pasos antes de un incidente.
Solo si la clave está diseñada para exposición del cliente (p. ej., clave de cliente de Google Maps restringida por ID de bundle). Secretos del servidor, claves secretas de Stripe y tokens de admin nunca pertenecen en EXPO_PUBLIC_*.
Por defecto a expo-secure-store para tokens en SDK 57. MMKV con encriptación es una opción para datos estructurados más grandes - aún requiere un ADR y una historia de gestión de claves; el almacenamiento seguro es más simple para artefactos de auth.
La mayoría de aplicaciones no deberían fijar inicialmente - TLS del sistema más ciclo de vida de certificado adecuado en el servidor es suficiente. Fija cuando el modelo de amenaza y operaciones de seguridad puedan poseer la rotación; documenta en un ADR.
EAS Secrets y variables de entorno se inyectan en tiempo de compilación/actualización en trabajadores de EAS - no significan automáticamente seguro para bundles del cliente. Solo valores no sensibles deberían alcanzar JS a través de extra o env público. Los secretos verdaderos permanecen del lado del servidor.
Expo Go usa el identificador de bundle de Expo - la redirección de OAuth y algunas restricciones de SDK difieren de producción. Prueba auth en dev-client o compilaciones de preview con tu ID de bundle real antes del lanzamiento.
Ejecuta npx expo config --type public con variables de entorno de producción e inspecciona la salida. Agrega CI grep para patrones como sk_live, BEGIN PRIVATE KEY y nombres de host internos.
Claves de auth de almacenamiento seguro, estado de sesión en memoria, cachés de consulta con PII y pila de navegación a auth - en ese orden. Verifica con prueba automatizada o Maestro smoke.
OTA puede eliminar una clave filtrada de nuevos bundles - pero instalaciones existentes pueden retener bundles antiguos hasta la actualización. Rota el secreto comprometido inmediatamente en el servidor; trata OTA como corrección de distribución, no rotación.
Solo cuando cumplimiento o política de fraude lo requiere - entiende que es eludible. Documenta limitaciones en ADR; no confíes en ello para autorización central.
Corta (minutos a decenas bajas de minutos) con rotación de actualización - las aplicaciones móviles son instalaciones de larga vida. Coordina lógica de actualización con manejadores de AppState background.
No - trata parámetros de URL como entrada no confiable. Nunca otorgues privilegios de ?role=admin. Valida sesión del lado del servidor.
Evita cachear imágenes sensibles en disco sin encriptación. Usa URLs firmadas que expiren y limpia cachés al logout.
No - los secretos aún se envían en bundles, las APIs de almacenamiento seguro son iguales. Mantén la misma checklist en RN 0.86.
Versiones de Stack: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última actualización: 9 jul 2026