Contenido del artículo
- En resumen
- Qué se revisa: tabla
- Datos en el teléfono
- Conexión con el servidor y la API
- Inicio de sesión, sesiones y permisos
- Pagos y compras dentro de la app
- Secretos en el código y protección contra el desmontaje
- El servidor de la app (backend)
- iOS y Android: en qué se diferencian
- Qué aporta el cliente
- Qué recibes como resultado
- Checklist antes de un pentest de app móvil
- FAQ
- Referencias
Un pentest de aplicación móvil revisa seis cosas: qué datos deja la app en el teléfono, cómo se comunica con el servidor y su API, cómo funcionan el inicio de sesión y las sesiones, si se puede saltar el pago, si hay contraseñas y claves metidas en el código y si el propio servidor de la app está protegido. Para iOS y Android la base es el estándar OWASP MASVS (una lista de requisitos de seguridad para apps móviles) y la guía OWASP MASTG (cómo comprobarlos), mientras que el servidor y la API se prueban con el método de OWASP para aplicaciones web. [1] [4]
Un pentest de aplicación móvil significa una revisión manual de la app y de su servidor en la que un especialista actúa como un atacante: desmonta la versión instalable, intercepta el tráfico e intenta llegar a datos, dinero o funciones ajenas. Abajo tienes una tabla con ejemplos de riesgo, una explicación de cada parte, qué darle al equipo de pruebas y qué recibes. El formato general del trabajo está en la página de pentest.
En resumen
- A octubre de 2026 las versiones vigentes son OWASP MASVS v2.1.0 (enero de 2024) y MASTG v2.0.0 (junio de 2026). Pregunta al proveedor con qué versiones trabaja. [2] [3]
- MASVS divide la revisión en ocho grupos: almacenamiento de datos, criptografía, acceso y permisos, red, interacción con el teléfono, calidad del código, resistencia al desmontaje y privacidad. [1]
- MASVS no cubre el servidor. Los problemas más graves suelen estar en la API, así que inclúyela en el alcance. [4]
- Del cliente se necesitan versiones para iOS y Android, cuentas de prueba para cada rol, una descripción de la API y un contacto del equipo de desarrollo.
- El resultado: un informe con hallazgos reproducidos, impacto en el negocio y orden de corrección, y una nueva prueba tras las correcciones si se acordó.
Qué se revisa: tabla
| Qué se revisa | Ejemplo de riesgo | Por qué le importa al negocio |
|---|---|---|
| Datos en el teléfono | El token de acceso y el número de tarjeta están en un archivo sin cifrar | Un teléfono perdido o infectado no debe convertirse en una fuga de datos de clientes |
| Conexión con el servidor | La app confía en cualquier certificado y el tráfico se puede alterar en una red pública | Nadie en medio lee ni cambia las peticiones de los clientes |
| API del servidor | Cambiar un número en la petición muestra el perfil de otro usuario | Un cliente no ve los datos de otro y una fuga no acaba en las noticias |
| Inicio de sesión y sesiones | El token antiguo sigue funcionando tras cerrar sesión, el código SMS se puede adivinar | No se puede tomar una cuenta ajena y una sesión robada caduca pronto |
| Pagos y compras | La app decide sola que la compra fue correcta y el servidor no lo comprueba | El acceso de pago no se regala y no hay pérdidas por fraude |
| Secretos en el código | La versión instalable contiene una clave de un almacenamiento en la nube o de un servicio de pagos | Nadie puede sacar la clave de la tienda de apps y usarla contra ti |
| Interacción con el teléfono | Otra app abre una pantalla interna mediante un enlace | Las demás apps del teléfono no obtienen acceso de más |
| Resistencia al desmontaje | Un límite o un control de acceso se desactiva fácilmente en una versión modificada | Las reglas importantes las aplica el servidor, no el teléfono del usuario |
Datos en el teléfono
El especialista instala la app, recorre los escenarios principales y mira qué queda en el dispositivo: archivos, base de datos local, registros, caché, copias de seguridad, capturas en el selector de apps. Un hallazgo típico: el token de sesión (un pase digital que se obtiene al iniciar sesión) o los datos personales guardados sin protección, aunque iOS y Android tienen almacenes protegidos para claves, Keychain y Keystore.
También se revisa qué acaba en los registros y en las copias de seguridad del teléfono. MASVS dedica un grupo propio de requisitos al almacenamiento de datos. [1]
Conexión con el servidor y la API
Una API es la forma en que la app habla con el servidor: cada botón de la app suele convertirse en una petición. El especialista intercepta esas peticiones y comprueba dos cosas. Primero, si la conexión está cifrada y si la app verifica el certificado del servidor, para que nadie en medio pueda cambiar la respuesta. Segundo, si el servidor comprueba cada petición en lugar de fiarse de la app.
El problema grave más frecuente parece sencillo: una petición lleva el número de un pedido o de un perfil y, si lo cambias, el servidor devuelve datos ajenos. La interfaz móvil nunca lo muestra, pero un atacante trabaja con las peticiones directamente, sin la app. Más sobre las pruebas de API en cómo se revisa la seguridad de una web y una API.
Inicio de sesión, sesiones y permisos
Aquí se recorre todo el camino del usuario: registro, inicio de sesión, recuperación de contraseña, acceso con huella o cara, cierre de sesión. Preguntas típicas: si se puede adivinar el código SMS, si la sesión termina al cerrar sesión y al cambiar la contraseña, si se puede saltar el acceso biométrico solo cambiando la respuesta en la app.
MASVS dice claramente que las decisiones de acceso las toma el servidor y que la app solo debe usar bien los protocolos de inicio de sesión. Las acciones sensibles, como una transferencia de dinero o el cambio de teléfono, necesitan una confirmación adicional. [8] Los roles se revisan aparte: si un usuario normal puede llamar a una función de gestor o de administrador.
Pagos y compras dentro de la app
Si la app tiene pagos, suscripciones o bonificaciones, el especialista busca la forma de obtener lo de pago sin pagar: cambiar el importe en la petición, repetir la petición de una bonificación, falsear una respuesta de «pagado». Para Android, Google aconseja directamente llevar la lógica sensible a tu propio servidor y verificar allí cada compra antes de dar acceso. [6]
El proveedor de pagos y las tiendas de apps pertenecen a otras empresas. No se prueban, solo se revisa tu integración con ellos.
Secretos en el código y protección contra el desmontaje
Cualquier versión de la App Store o de Google Play se puede descargar y desmontar. Por eso el especialista busca contraseñas, claves de API, direcciones de servicios internos y accesos de prueba metidos en ella. OWASP describe los secretos incrustados en el paquete de la app como una debilidad propia. [5] La regla es sencilla: todo lo que está dentro de la app tarde o temprano lo verá alguien ajeno.
La resistencia al desmontaje (protección contra cambios y copias de la app) no la necesita todo el mundo. En apps bancarias, juegos con objetos de pago o apps con contenido valioso se revisa más a fondo: si la app funciona en un teléfono con la protección del sistema rota (root o jailbreak), si detecta cambios en su propio código. Pero esta protección solo dificulta el ataque, y las reglas importantes las tiene que seguir aplicando el servidor.
El servidor de la app (backend)
El backend significa los servidores y bases de datos con los que trabaja la app. MASVS y MASTG no lo cubren y recomiendan revisarlo aparte con los estándares de OWASP para aplicaciones web, entre ellos la guía WSTG. [4] [7] En la práctica, un pentest móvil sin la API da una imagen incompleta: la app puede estar bien hecha y el servidor entregar datos ajenos a cualquiera que conozca la dirección de la petición.
Por eso el alcance debe decirlo de forma explícita: app de iOS, app de Android, API y panel de administración si lo hay. Si algo queda fuera, el informe debe mostrarlo.
iOS y Android: en qué se diferencian
Los requisitos de MASVS son los mismos para las dos plataformas, y los métodos de prueba de MASTG están escritos por separado para cada una. [3] Cambian los almacenes protegidos, las reglas de permisos, la forma en que otras apps pueden abrir tus pantallas y las herramientas de análisis. Por eso las dos versiones de una misma app se prueban por separado: un fallo suele existir solo en una plataforma, porque las escriben personas distintas.
Qué aporta el cliente
MASVS recomienda el formato de «libro abierto»: el especialista tiene acceso al equipo de desarrollo, a la documentación, al código fuente y al menos a una cuenta por cada rol. [4] Lo mínimo que conviene preparar:
- versiones para iOS (por TestFlight o como archivo para un dispositivo de prueba) y Android (archivo APK o AAB), a ser posible sin protección extra contra el desmontaje para la parte principal de la prueba;
- dos cuentas de prueba por rol, para comprobar si un usuario llega a los datos de otro;
- una descripción de la API o una colección de peticiones y la dirección del servidor de pruebas;
- tarjetas de prueba o el entorno de pruebas del proveedor de pagos, si hay pagos;
- un contacto de desarrollo para dudas rápidas y una autorización por escrito con el alcance.
La lista completa de pasos está en cómo prepararse para un pentest.
Qué recibes como resultado
- Un resumen breve para la dirección: qué se encontró, qué significa para el negocio y qué corregir primero.
- Hallazgos con pasos para reproducirlos, pruebas y valoración del riesgo, por separado para iOS, Android y la API.
- Recomendaciones concretas para el equipo de desarrollo, no consejos generales.
- Una lista de lo que se revisó y de lo que quedó fuera.
- Una nueva prueba tras las correcciones, si está acordada en el contrato, con confirmación por escrito de lo que quedó cerrado.
El plazo depende del número de plataformas, roles y funciones, así que se fija antes de empezar. Si el alcance aún no está claro, empieza por describir la app y por un pentest de los escenarios más importantes: inicio de sesión, datos de clientes y pagos.
Checklist antes de un pentest de app móvil
Descargar la lista de preparación (PDF)PDF · A4
FAQ
¿Qué se revisa en un pentest de aplicación móvil?
Los datos que la app guarda en el teléfono, la conexión con el servidor y la API, el inicio de sesión y las sesiones, los pagos, los secretos metidos en el código, la interacción con otras apps y, si hace falta, la resistencia al desmontaje. La base es OWASP MASVS y MASTG, y el servidor se prueba con el método de OWASP para aplicaciones web.
¿Hay que probar iOS y Android por separado?
Sí. Los requisitos son los mismos, pero las plataformas guardan los datos y dan acceso a otras apps de forma distinta, y el código suelen escribirlo equipos diferentes. Un fallo en una versión no significa que exista en la otra, ni al revés.
¿La API entra en el pentest de una app móvil?
Debería, pero conviene ponerlo por escrito. MASVS solo cubre la app, mientras que los problemas más graves, como el acceso a datos ajenos, suelen estar en el servidor.
¿Hace falta entregar el código fuente?
No es obligatorio, la prueba se puede hacer solo con las versiones instalables. Pero con código y documentación la revisión llega más hondo en el mismo tiempo, y MASVS recomienda justo ese formato abierto.
¿Cada cuánto hay que hacer un pentest de una app móvil?
Normalmente una vez al año y tras cambios grandes: pagos nuevos, un nuevo método de acceso, un cambio de servidor. Entre pentests ayudan las comprobaciones automáticas en el proceso de compilación de la app.
Referencias
- OWASP MASVS: The Mobile Application Security Verification Standard mas.owasp.org
- OWASP MASVS v2.1.0 release (January 2024) github.com
- OWASP MASTG v2.0.0 release (June 2026) github.com
- OWASP MASVS: Assessment and Certification mas.owasp.org
- OWASP MASWE-0004: Sensitive Data Hardcoded in the App Package mas.owasp.org
- Android Developers: Play Billing, Fight fraud and abuse developer.android.com
- OWASP Web Security Testing Guide wstg.owasp.org
- OWASP MASVS-AUTH: Authentication and Authorization mas.owasp.org
