La seguridad en apps móviles se revisa en seis frentes antes de lanzar: cómo se autentica el usuario, dónde se guardan los tokens, qué permisos pide la app, cómo viaja la información, qué reglas protegen el backend y qué pruebas se hicieron. La mayoría de los problemas serios no están en el código del teléfono sino en el servidor que lo atiende, y por eso la revisión mira ambos lados.
Esta es la lista que usamos internamente. Sirve para una app de una clínica, de una urbanización o de un comercio, y también para auditar una app que otro equipo construyó.
1. Autenticación: quién entra y cómo
- Proveedor de identidad probado (Firebase Auth, Supabase Auth, Sign in with Apple, Google) en lugar de un sistema de claves hecho a mano.
- Límites de intentos para evitar que alguien pruebe miles de contraseñas o códigos.
- Sesiones que expiran y se pueden cerrar desde el servidor, por ejemplo cuando el usuario cambia su clave o reporta su teléfono perdido.
- Doble factor o verificación extra para acciones sensibles: cambiar el correo, ver datos médicos, confirmar un pago.
- Mensajes de error neutros que no revelen si un correo está registrado o no.
2. Almacenamiento seguro de tokens y datos locales
Cuando el usuario inicia sesión, la app recibe un token que funciona como llave. Si esa llave queda en un lugar que cualquier otra app o una copia de respaldo puede leer, el problema es grave.
- En iOS, el Keychain; en Android, el Keystore o el almacenamiento cifrado. Nunca en UserDefaults, SharedPreferences ni archivos planos.
- Nada de claves de servicios en el código de la app. Todo lo que viaja dentro del binario se puede extraer. Las llaves privadas viven en el servidor.
- Datos sensibles en caché, solo lo necesario y cifrados. Al cerrar sesión, se borran.
- Capturas y vista previa: en pantallas con datos delicados conviene ocultar el contenido cuando la app pasa a segundo plano.
3. Permisos: pedir solo lo que se usa
Cada permiso (ubicación, cámara, contactos, micrófono) es una superficie de riesgo y una razón para que el usuario desconfíe. Las tiendas de Apple y Google además revisan que cada permiso tenga una justificación clara.
- Pide el permiso en el momento en que se necesita, no todos al abrir la app.
- Ubicación «mientras se usa» salvo que de verdad necesites seguimiento en segundo plano, como en una app de reparto.
- Textos de justificación honestos, que expliquen para qué se usa el dato.
- Revisa las librerías de terceros: algunas piden permisos o recolectan datos que tu equipo no sabía.
4. Comunicación cifrada
Toda conexión de la app con tus servidores va por HTTPS con TLS actualizado. iOS y Android ya bloquean por defecto el tráfico sin cifrar, así que una excepción en la configuración es una señal de alerta que hay que justificar. Para apps que manejan dinero o datos muy sensibles, se puede sumar certificate pinning, con un plan claro para rotar certificados sin dejar la app inservible.
5. Reglas del backend: donde de verdad se juega la seguridad
Todo lo que la app valida, alguien puede saltárselo con una herramienta que hable directo con tu servidor. Por eso las reglas que importan están del lado del backend.
- Cada petición se autoriza en el servidor: el usuario A no puede leer el pedido del usuario B cambiando un número en la URL.
- Reglas de la base de datos revisadas si usas Firebase o Supabase: reglas de Firestore y Storage, políticas RLS en PostgreSQL. Una regla demasiado abierta expone toda la base.
- Precios, saldos y estados se calculan en el servidor, nunca se confía en el valor que manda el teléfono.
- Validación de todas las entradas y límites de uso para evitar abusos.
- Registros de auditoría de acciones sensibles, sin guardar datos personales de más.
Si estás eligiendo plataforma de backend, en Supabase, Firebase o servidor propio comparamos cómo se protege cada una.
6. Pruebas antes de publicar
- Pruebas de las reglas del backend con usuarios distintos: intentar leer y escribir datos ajenos debe fallar siempre.
- Revisión de dependencias en busca de librerías con vulnerabilidades conocidas o abandonadas.
- Análisis del binario compilado para confirmar que no viajan llaves, URLs internas ni registros de depuración.
- Pruebas de sesión: cerrar sesión, cambiar clave, reinstalar la app y verificar que no quedan datos ni accesos viejos.
- Prueba de tráfico con un proxy para confirmar que todo viaja cifrado y que el servidor rechaza peticiones manipuladas.
- Revisión contra las guías de las tiendas y contra la Ley de Protección de Datos Personales en lo que aplique.
Para apps con datos de salud, pagos o ubicación de personas, conviene sumar una revisión externa antes del lanzamiento. Sobre el marco legal general, lo explicamos en la LOPDP aplicada a tu software.
Después del lanzamiento
La seguridad no termina con la publicación. Hay que actualizar dependencias, revisar alertas, rotar credenciales y repetir la revisión cada vez que se agrega una función que toca datos sensibles. Las amenazas generales que rodean a la app, como el phishing o las claves filtradas del equipo, las cubrimos en ciberseguridad para empresas en Ecuador.
En FoodTook Labs construimos apps nativas en SwiftUI y Kotlin, y operamos en producción nuestra propia plataforma de delivery con app de cliente, de repartidor y paneles. Esta lista sale de ese trabajo diario. Si tienes una app por lanzar o una ya publicada que quieres revisar, conversemos.