Pentesting de aplicaciones móviles (iOS y Android)

Enfoques: caja negra, caja gris y caja blanca

Los tres enfoques existen y no responden a la misma pregunta. En una aplicación móvil la diferencia está sobre todo en lo que nos entregas al principio: la build publicada y nada más, cuentas de prueba para cada rol, o el código fuente y la configuración del backend.

Caja negra (black box)

Partimos de la build publicada, sin cuentas ni documentación, igual que el atacante oportunista que se descarga tu app de la tienda. Sirve para medir la exposición pública; se queda corto para cubrir las funciones que solo ven las personas autenticadas.

Caja gris (grey box)

Disponemos de cuentas de prueba para cada rol y de una descripción funcional. Es el enfoque que recomendamos en la mayoría de los proyectos móviles: con las mismas jornadas se llega a probar la autorización entre usuarios, los flujos de pago y la API.

Caja blanca (white box)

Añadimos el código fuente, una build de depuración y, si hace falta, la configuración del backend. El análisis estático gana profundidad: secretos de compilación, lógica de negocio sensible, criptografía mal implementada. Es lo indicado antes de una salida a producción delicada o en una aplicación de pagos.

A igualdad de jornadas, la caja gris cubre más funcionalidad, porque no se va media parte del presupuesto en crear cuentas y dibujar flujos en lugar de buscar vulnerabilidades. El enfoque elegido queda escrito en el presupuesto.

Alcance y planificación

El alcance determina el valor de un test mucho más que el número de jornadas vendidas. Se acuerda en una reunión corta y fija:

• los objetivos: plataformas (iOS, Android o ambas), la build concreta y su versión, las cuentas y los roles, y los dominios y las API que la aplicación consume;
• las exclusiones: servicios de terceros, pasarelas de pago en producción, denegación de servicio y cualquier acción destructiva;
• la ventana de ejecución y una persona de contacto localizable por tu parte durante todo el trabajo;
• las reglas de enfrentamiento (rules of engagement): hasta dónde se autoriza explotar, cómo se tratan los datos reales y qué hacemos si aparece un hallazgo crítico, que te comunicamos en el momento y sin esperar al informe;
• el entorno: preproducción equivalente a producción cuando existe, y producción con precauciones reforzadas cuando no la hay.

En móvil hay dos decisiones que conviene tomar antes y no sobre la marcha. La primera es si el backend entra en el alcance: cuando la app es un cliente ligero, dejarlo fuera es dejar fuera el riesgo. La segunda es qué build se prueba —la de la tienda, una firmada de TestFlight o un canal interno de Google Play—, porque una build de depuración se comporta de otra manera y un informe sobre ella no describe lo que usan tus clientes.

El presupuesto sale del alcance: jornadas, personas asignadas, fecha de entrega y plazo de retest. Si lo que describes no justifica un test de intrusión, te lo decimos antes de presupuestarlo.

Entregables: informe, sesión de resultados y retest

Lo que compras no es una semana de pruebas, es lo que queda después. Tres entregables, ninguno opcional. Puedes pedir un informe de ejemplo anonimizado antes de firmar, para saber exactamente qué vas a recibir.

El informe

Un resumen ejecutivo de dos páginas para dirección: nivel de riesgo, hallazgos principales y decisiones que hay que tomar, sin jerga. Después, una ficha por vulnerabilidad: descripción, criticidad CVSS y criticidad de negocio, categoría MASVS afectada, prueba de explotación reproducible, corrección recomendada y esfuerzo estimado. Los anexos recogen el alcance, la metodología y la lista de pruebas realizadas, incluidas las que no dieron resultado, que suele ser la parte más útil delante de la entidad auditora. Se entrega en español y en PDF, con una tabla de seguimiento importable.

La sesión de presentación de resultados

Una hora por videoconferencia, conducida por quien ha hecho las pruebas y no por un comercial. Tu equipo de desarrollo pregunta, volvemos a ejecutar en pantalla la explotación que haga falta y priorizamos juntos el plan de corrección. Si lo necesitas, añadimos una segunda sesión corta para dirección.

El retest o contraauditoría

Cuando despliegas las correcciones, repetimos los escenarios afectados y publicamos una versión actualizada del informe que indica qué está cerrado y qué no. Está incluido en el precio, sin coste adicional, dentro de los 90 días siguientes a la entrega del informe inicial. Es una partida que el mercado suele facturar como jornada aparte.

Si pruebas las dos plataformas, iOS y Android se documentan por separado: una corrección aplicada en Android no vale como prueba en iOS.

Qué obliga realmente en España a probar una aplicación móvil

Conviene separar lo que está en vigor de lo que se anuncia. A 12 de septiembre de 2026, la Directiva NIS2 no está transpuesta en España: el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad solo ha pasado una primera lectura en el Consejo de Ministros, el 14 de enero de 2025, no ha llegado a las Cortes, y la Comisión Europea llevó a España ante el Tribunal de Justicia de la Unión Europea el 9 de julio de 2026 mediante el procedimiento INFR(2024)0270. En materia de seguridad de las redes y sistemas de información, lo que sigue vigente es el Real Decreto-ley 12/2018 y su reglamento de desarrollo, el RD 43/2021. Quien te venda hoy una app «conforme a NIS2» te está vendiendo una ley española que todavía no existe.

Lo que sí obliga, y obliga ahora, es esto.

RGPD, art. 32.1.d)

Si tu aplicación trata datos personales —y casi todas lo hacen—, el art. 32.1.d) del RGPD exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento». Es la base europea más clara de una prueba periódica y es directamente aplicable: no depende de ninguna transposición.

Reglamento de Ejecución (UE) 2024/2690

Para proveedores de servicios digitales —computación en nube, centros de datos, redes de distribución de contenidos, servicios gestionados de seguridad, mercados en línea, motores de búsqueda, plataformas de redes sociales y prestadores de servicios de confianza— este reglamento es de aplicación directa y no espera a la ley española. Su anexo, en el punto 6.5 «Pruebas de seguridad», pide una política de pruebas documentada, un alcance y una frecuencia basados en el riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. Un pentest de la app y de su API, con informe y retest, es exactamente la evidencia que ese punto reclama.

ENS: RD 311/2022

Si la aplicación es un canal de un servicio público, o se la prestas a una administración, forma parte del sistema sujeto al Esquema Nacional de Seguridad. El art. 31 fija una auditoría regular ordinaria al menos cada dos años; el art. 38 separa la autoevaluación de la categoría BÁSICA de la certificación exigida en MEDIA y ALTA. En el Anexo II, el refuerzo R6 de la medida [op.mon.3] incluye el subrequisito [op.mon.3.r6.3], literalmente «Pruebas de penetración», aplicable en categoría ALTA. Y si el backend de tu app corre en un proveedor de nube de un tercero que no es conforme con el ENS, la medida op.nub.1.2 a) pide «Auditoría de pruebas de penetración (pentesting)» ya desde categoría BÁSICA.

DORA: Reglamento (UE) 2022/2554

Se aplica desde el 17 de enero de 2025. Si eres entidad financiera, tu app de banca o de pagos forma parte del marco de gestión del riesgo de las TIC, y el art. 26 exige pruebas avanzadas basadas en amenazas (TLPT) al menos cada tres años a las entidades designadas. Nosotros no realizamos TLPT, y lo explicamos más abajo.

Nada de esto es asesoramiento jurídico: un test de intrusión es una constatación técnica, no un dictamen sobre las obligaciones que aplican a tu organización. Lo que sí te podemos decir es qué evidencia produce nuestro informe y para qué expediente sirve. Lo desarrollamos en NIS2 en España: qué obliga hoy y qué no y en qué exige realmente el ENS sobre pentesting.

Última verificación: 12 de septiembre de 2026.

Tratamiento de datos y soberanía

Un pentest móvil te obliga a entregar cosas sensibles: la build firmada, a veces el código fuente, cuentas reales y, en las capturas del informe, datos que pueden ser personales. Dónde acaban esos ficheros es una pregunta legítima y tiene una respuesta corta.

Haxoris es una empresa establecida en la Unión Europea. Trabajamos desde la Unión Europea y todo lo que se genera durante el proyecto —builds, capturas, extractos de registros, notas de prueba e informes— se almacena y se copia dentro de la Unión Europea.

La consecuencia práctica es que el RGPD se nos aplica directamente. No hay transferencia internacional del capítulo V del RGPD que justificar, no hay cláusulas contractuales tipo que negociar y no hay que construir una evaluación de impacto de las transferencias. Actuamos como encargado del tratamiento en el sentido del art. 28 del RGPD; la lista de subencargados y de sus países te la damos antes de firmar y te notificamos cualquier cambio. Al no estar sometidos a la jurisdicción de Estados Unidos, no nos alcanza la CLOUD Act.

Los datos de prueba se cifran en reposo y en tránsito, solo acceden a ellos las personas asignadas a tu proyecto y se borran en el plazo pactado en contrato, por defecto al vencer el plazo de retest. El informe es tuyo: no lo reutilizamos y no citamos tu nombre sin tu autorización por escrito.

Si lo que te frena es contratar a un proveedor que no está establecido en España, lo tratamos entero en contratar una empresa de pentesting no española.

Qué no hacemos

Decirlo es lo que hace creíble el resto.

• No certificamos. Haxoris no es entidad de certificación acreditada por ENAC y no expide certificaciones de conformidad con el ENS, ni el Distintivo de Conformidad, ni certificados ISO 27001. Emitimos un informe técnico de resultados: la certificación la expide un organismo de certificación acreditado, y nuestro informe le sirve de evidencia.
• No realizamos TLPT. Las pruebas avanzadas basadas en amenazas del art. 26 de DORA exigen proveedores que cumplan el art. 27 del mismo reglamento, y el ejercicio lo dirige el supervisor, no el proveedor. Un pentest o un ejercicio de Red Team de Haxoris puede ser preparación previa, pero no lo sustituye ni lo realizamos.
• No trabajamos con información clasificada. Ese trabajo exige una habilitación de seguridad de empresa que no tenemos, y lo decimos antes de que nos lo preguntes.
• No sustituimos una revisión exhaustiva del código. Un test de intrusión está acotado en tiempo y va detrás del impacto explotable. Si lo que necesitas es cobertura línea a línea de un componente crítico, es otro servicio y te lo diremos en el momento del alcance.