Pentesting de aplicaciones móviles: por qué tu app lo necesita

El pentesting de aplicaciones móviles revisa qué guarda tu app en el teléfono, qué manda por la red y qué puede hacer alguien con ella una vez descargada. Se audita contra OWASP MASVS, a mano, y parte de 1.140 €.

La diferencia con una auditoría web está en el punto de partida. Una aplicación web vive en tu servidor. Una app móvil vive en un teléfono que no controlas, y cualquiera puede bajarla de la tienda, abrirla y leer lo que lleva dentro. Ese es el trabajo del atacante, y es por donde empieza el nuestro.

Por qué la app se queda fuera de la auditoría

Casi siempre es un problema de reparto. Seguridad audita la infraestructura. Desarrollo publica la app. Nadie la tiene en su lista. Cuando además la mantiene un proveedor externo, el hueco crece: se revisa el contrato y no el binario.

Hay una razón técnica encima. La app no está en tu perímetro, así que no aparece en un escaneo de red ni en el inventario de activos expuestos. Para verla hay que ir a la tienda y descargarla, exactamente igual que haría cualquiera.

Qué se encuentra al auditar apps de verdad

No es una impresión nuestra. En su Global Mobile Threat Report de 2025, Zimperium midió que el 43 % de las aplicaciones Android y cerca del 60 % de las de iOS son vulnerables a fugas de datos personales, y que más del 60 % de las de iOS no llevan protección básica del código.

El dispositivo tampoco ayuda. Ese mismo informe cifra en más del 50 % los teléfonos que funcionan con un sistema operativo desactualizado o comprometido. Una app bien construida sigue expuesta si no comprueba dónde se está ejecutando.

Los diez riesgos que mide OWASP

El Mobile Top 10 de OWASP, en su edición de 2024, ordena lo que de verdad se explota. Traducido a lo que se ve en una auditoría:

Los dos primeros son los que más han cambiado el trabajo en los últimos años. Ya no basta con revisar el código propio: hay que mirar qué entra con cada dependencia, quién la mantiene y qué permisos se llevó el día que se integró.

Qué se rompe, en concreto

En el teléfono

Lo primero que se mira es qué queda escrito cuando la app se cierra. Tokens de sesión, credenciales y datos de cliente aparecen en bases de datos locales, en preferencias sin cifrar y en los registros del sistema. En Android, un android:allowBackup a true en el AndroidManifest.xml permite sacar esos ficheros con adb backup sin tocar el teléfono por dentro.

Lo correcto es que los secretos vivan en el Keystore de Android o en el Keychain de iOS, y que nada sensible acabe en un registro. Suena obvio y es de lo que más encontramos.

En la red

El cifrado en tránsito está casi siempre. Lo que falta es la fijación de certificado, y sin ella basta con instalar un certificado propio en el teléfono para leer todo el tráfico entre la app y su servidor. En iOS conviene además comprobar que nadie ha desactivado App Transport Security con NSAllowsArbitraryLoads en el Info.plist para salir de un apuro en desarrollo.

En el binario

Una app publicada es un fichero que cualquiera descarga y descomprime. Dentro aparecen direcciones de entornos de pruebas, claves de servicios de terceros y la lógica de negocio que se puede modificar en tiempo de ejecución. Si una comprobación importante vive solo en la app, no es una comprobación.

En lo que viene de fuera

Los SDK de analítica, publicidad y pagos entran con los permisos que pidieron el día que se integraron. Una app con cuatro SDK hereda la superficie de los cuatro, y el equipo que la mantiene solo escribió el código del primero. Es el punto que más sorprende en la presentación de resultados.

La vía más rentable, aun así, suele ser la API. La app es el cliente; el trabajo lo hace el backend. Si la API confía en que quien llama es la app, basta con hablar con ella directamente y saltarse todas las comprobaciones de la pantalla. Por eso una auditoría de app acaba mirando también el pentesting de APIs.

Cómo se prueba un pentesting de aplicaciones móviles

MASVS es el estándar de verificación de OWASP para aplicaciones móviles y MASTG es la guía de pruebas que lo acompaña. El primero dice qué hay que cumplir; el segundo, cómo se comprueba. Auditamos contra los dos, en iOS y en Android.

El análisis estático lee el binario y su configuración. El dinámico ejecuta la app y comprueba lo que el estático solo puede sospechar. Los dos hacen falta: un secreto escrito en el código lo ve el primero, y una sesión que no caduca al cambiar la contraseña solo la ve el segundo.

Qué se juega la empresa

Depende de lo que guarde la app, y conviene decirlo en plazos y en dinero. En abstracto no mueve a nadie.

Si el fallo da acceso a datos de clientes, hay una brecha que notificar. El RGPD da 72 horas desde que se conoce, y el reloj empieza antes de que nadie sepa el alcance real. Lo contamos paso a paso en qué hacer ante una brecha de datos.

Si el fallo permite suplantar a un usuario, el problema deja de ser de datos y pasa a ser de dinero: pedidos, pagos y devoluciones hechos con la cuenta de otro, y un servicio de atención que no sabe qué contestar.

Y queda el coste que no se factura. Una app retirada de la tienda mientras se corrige es una semana sin canal de venta, y la revisión para volver a publicarla no la controlas tú.

Cómo trabajamos: seis fases

El proceso es el mismo en las trece auditorías que hacemos, y esa es la parte que tranquiliza a un equipo de desarrollo: sabe qué va a pasar y cuándo.

1. 01Kick-off: alcance, calendario, cuentas de prueba y reglas del juego.
2. 02Plan de auditoría por escrito, con fechas de inicio y fin, pruebas previstas y equipo auditor.
3. 03Ejecución. Si aparece algo crítico, se avisa en el momento y no se espera al informe.
4. 04Informe técnico: cada vulnerabilidad con impacto, criticidad y evidencia. Si se explotó, con los pasos para reproducirla.
5. 05Presentación de resultados para perfiles no técnicos, con las dudas resueltas. Entregamos el PowerPoint que usamos.
6. 06Retest: seis meses para corregir y después una verificación nueva, con informe nuevo.

Qué te llevas

Un informe técnico con cada hallazgo, su criticidad y su evidencia, un resumen ejecutivo para dirección y la presentación con la que lo explicamos. Si quieres el detalle de qué debería traer, lo desglosamos en qué debe incluir un informe de pentesting.

Cada vulnerabilidad va con los pasos para reproducirla. Tu equipo puede comprobarla sin llamarnos, y esa es la diferencia entre un informe que se archiva y uno que se corrige.

Cuánto cuesta y cuánto dura

Un pentesting de aplicación móvil parte de 1.140 €. La auditoría de la API que hay detrás parte de 760 €. El precio final depende del número de pantallas, de los roles de usuario y de si entran iOS, Android o los dos.

En tiempo, de una a tres semanas desde el kick-off hasta la presentación. Para no perder días, la app tiene que llegar en una versión estable y con cuentas de prueba de cada rol.

Qué preparar antes de contratar

1. 01Decide el alcance: qué plataformas, qué versión y si entra el backend.
2. 02Prepara cuentas de prueba de cada rol y avisa a quien mantenga la API.
3. 03Reúne el AndroidManifest.xml, el Info.plist y la lista de dependencias de terceros.
4. 04Pide un informe de ejemplo y mira si trae evidencias o solo una lista de fallos.
5. 05Comprueba que el retest está incluido y con qué plazo.
6. 06Acuerda a quién se avisa si aparece algo crítico a mitad de auditoría.

Con eso resuelto, la auditoría empieza el primer día. Sin ello, la primera semana se va en conseguir un usuario de pruebas.