La idea más importante de la seguridad móvil cabe en una frase: tu app corre en un teléfono que no controlas. Cualquiera con paciencia puede descargarla, abrirla y leer lo que trae dentro. Casi todos los errores graves vienen de olvidarlo.
No necesitas programar para exigir lo básico. Basta con hacer las preguntas correctas.
1. Ninguna llave importante dentro de la app
Las llaves de pagos, inteligencia artificial o servicios en la nube no deben ir en el código de la app, porque se pueden extraer. Ofuscar el código lo dificulta, pero no lo impide.
La regla es que la app hable con tu servidor y sea el servidor quien guarde las llaves y llame al servicio externo. Este problema nos importa tanto que construimos wenlucer, un proxy para compartir acceso a una API sin entregar la llave.
Pregunta: ¿qué llaves viven dentro de la app y qué pasa si alguien las saca?
2. El servidor es quien decide
Una app modificada puede enviar lo que quiera. Si el precio, el descuento o el permiso de administrador se decide en el teléfono, alguien lo va a cambiar.
Toda regla importante debe validarse en el servidor: qué puede ver cada usuario, qué puede modificar y cuánto cuesta algo. El clásico error es cambiar un número en la petición y ver los datos de otro cliente.
Pregunta: ¿qué pasa si alguien cambia el número de cliente en una petición?
3. Datos cifrados, en el viaje y en el teléfono
- En el viaje: todo por HTTPS, sin excepciones.
- En el teléfono: las sesiones y los datos sensibles van en el almacén seguro del sistema (Keychain en iOS y Keystore en Android), no en un archivo cualquiera.
- Lo mejor es no guardar. Si un dato no necesita estar en el teléfono, que no esté.
4. Permisos mínimos
Pide solo lo que usas y pídelo cuando haga falta, explicando para qué. Una app de pedidos que al abrirse pide contactos y micrófono genera desconfianza. Además, lo que recoges debe coincidir con lo que declaras a las tiendas, como vemos en privacidad en App Store y Google Play.
5. Dependencias vigiladas
Una app moderna trae decenas de bibliotecas de terceros, y una vulnerabilidad en cualquiera es también tuya. También responden por ellas ante las tiendas: lo que recoge un SDK de terceros cuenta como recogido por tu app.
Revisarlas debe ser parte del mantenimiento, no algo que se hace cuando ya hubo un problema.
6. Registros limpios
Los registros y reportes de errores suelen terminar en servicios externos. Si incluyen contraseñas, tokens o datos personales, acabas de copiar esa información a donde nadie la está cuidando. Hay que filtrar antes de enviar.
Cuentas y sesiones
Vale la pena añadir algunas decisiones sobre el acceso:
- Passkeys o inicio de sesión con proveedores confiables, en lugar de contraseñas propias, cuando se pueda. Lo explicamos en passkeys.
- Sesiones revocables: si alguien pierde el teléfono, debes poder cerrar su sesión desde el servidor.
- Borrado de cuenta real: las dos tiendas lo exigen, y debe borrar de verdad.
Si manejas datos sensibles
Banca, salud, menores o datos biométricos cambian la conversación. Además de una revisión profesional de seguridad, Apple pide que las apps de áreas muy reguladas las envíe la entidad legal que presta el servicio. En esos casos, publicar con una cuenta ajena no es opción, como explicamos en tu cuenta o la de un publisher.
Lo que esta lista no sustituye
Este es un mínimo, no una auditoría. Si tu app mueve dinero o datos delicados, pide una revisión independiente; la guía OWASP MASVS es una buena referencia para pedirla.
Si quieres revisar una app que ya existe, escríbenos. Estos seis puntos se comprueban antes de lo que parece.