Robo de datos, malware, API pirateadas... El uso de aplicaciones móviles se dispara, y con él los ataques. ¿Son realmente seguras sus aplicaciones móviles? Más allá del simple cifrado, ¿cómo garantizar una seguridad real sin perjudicar la experiencia del usuario? ¿Cómo gestiona el almacenamiento seguro o el endurecimiento ¿Cliente/servidor? ¿Y sus pruebas? ¿Cumplen con los estándares actuales? Descubra las prácticas y herramientas esenciales para codificar aplicaciones seguras, eficaces... y que realmente inspiran confianza.
En primer lugar, pongamos en contexto algunas cifras. En 2024, Akamai registró nada menos que 311 000 millones de ataques. ¿Lo más llamativo? Que casi la mitad de ellas apuntan directamente a las API que sirven como puertas traseras. El primer gran reto para los desarrolladores.
Pero estos no son los únicos ataques contra los móviles, ¡ni mucho menos! En 2025, la presión se intensifica. Los ataques contra los smartphones Android se han disparado. de 29 % en el primer semestre de 2025 en comparación con el año anterior, según Kaspersky..
Los ciberdelincuentes no buscan muy lejos: se centran en lo que les reporta beneficios inmediatos. Las contraseñas de un solo uso (OTP) para eludir la autenticación de dos factores, las carteras para sustraer activos digitales y, por supuesto, los datos bancarios, que siguen siendo su santo grial.
Android es el objetivo preferido, pero iOS ya no es ese santuario inviolable que imaginábamos hace unos años.
Por lo tanto, la seguridad de las aplicaciones móviles se convierte en una prioridad.
La amenaza en cifras: la explosión de la superficie de ataque
| Objetivo del ataque | Estadísticas (2025) | Impacto para el desarrollador |
|---|---|---|
| Ataques a aplicaciones | 83 % organizaciones atacadas en enero 2025 (65 % en 2024) (Digital.ai) | Priorizar pruebas continuas, endurecimiento del cliente |
| Ataques API | > 40 000 incidentes en el S1 2025 (Thales) | Controle cada punto final + antiauso (detección/bloqueo de usos indebidos, bots, fraude) |
| Vulnerabilidades IA/API | + 1025 % de IA-CVE en 2024 de 98,9 % relacionadas con las API (Wallarm) | Prueba las entradas/salidas y los controles AAA |
| Amenazas para Android |
+ 29 % ataques S1 2025 vs S1 2024 (Kaspersky) |
Imponer Anti-tamper (impide que se modifique la aplicación) y la detección del entorno |
| Coste medio de una infracción | 4,88 M$ (IBM) | La inercia cuesta más caro que las herramientas |
Su hoja de ruta: tres pilares para una defensa móvil
Ante esta avalancha, las listas de verificación garabateadas en un rincón de la mesa ya no son suficientes. Necesita una arquitectura de defensa sólida, basada en tres pilares complementarios que se refuerzan mutuamente.
1er Pilar: el marco de referencia que estructura su enfoque.
Antes incluso de escribir una línea de código, necesita puntos de referencia. Eso es precisamente lo que le ofrece El Top 10 móvil de OWASP en su versión 2024.
Este referencial identifica los diez riesgos principales que amenazan a sus aplicaciones móviles, desde el almacenamiento no seguro hasta la criptografía débil, pasando por las inyecciones de código. Cada riesgo está documentado, explicado y contextualizado. Y el OWASP Mobile Top 10 le ofrece soluciones para cada problema.
Además, este marco sirve como base para el debate con cualquier equipo de seguridad.
Pero un catálogo de peligros no es suficiente. Es necesario poder traducir estas amenazas abstractas en acciones concretas, y ahí es donde entra en juego el MASVS v2 (Estándar de verificación de seguridad de aplicaciones móviles).
Esta norma actúa como traductor universal entre el mundo de los riesgos y el de los desarrolladores.
Tomemos un ejemplo concreto: el riesgo «almacenamiento de datos no seguro» se convierte en el MASVS en un requisito preciso y verificable: «la aplicación no debe almacenar ningún secreto sin cifrar en las preferencias». Se acabó la ambigüedad, ahora hay criterios claramente definidos.
Siga la guía MASTG
Para confirmar que cumple con estos requisitos, puede basarse en el MASTG, la Guía de pruebas de seguridad de aplicaciones móviles, que le proporciona escenarios de prueba prácticos y reproducibles.
Esta trilogía OWASP-MASVS-MASTG constituye la columna vertebral de su garantía de calidad y seguridad.
Hélène, directora de ingeniería en una estructura B2B, cuenta cómo su equipo transformó el MASVS en un backlog de producto:
«Cuando decidimos tomar el MASVS En serio, hemos dejado de lado las grandes declaraciones para pasar a la acción. diferencias concretas. Teníamos 17 puntos rojos en la parte RESILIENCIA : anti-debug, anti-hook, fuga de registros... Hemos montado un tablero único compartido entre desarrolladores, control de calidad y seguridad, y planificado dos sprints específicos. A cada historia de usuario, una prueba MASTG se exigía. Resultado: en tres semanas, se acabaron los bypass fáciles y se formó un equipo. alineada sobre la misma base interpretativa. Hoy en día, ya no se discute: si es grave, se medida. "
2.º pilar: defensa activa por parte del cliente
Su aplicación se ejecuta en un dispositivo que usted no controla. Es un hecho. El usuario puede tener rooteado su Android, liberado su iPhone, o peor aún, instalado malware que escucha todo lo que transita. La pregunta fundamental entonces es: ¿cómo saber si realmente está hablando con SU aplicación y que el dispositivo está sano?
La respuesta pasa por el’certificado físico, esta capacidad de vincular su aplicación al Módulo de seguridad de hardware (HSM) del aparato.
En Android, esto significa migrar sin demora hacia Integridad en el juego (que sustituyó a SafetyNet). Play Integrity no solo verifica la integridad del binario, sino que también certifica el estado real del entorno: presencia de raíz, detección de malware, signos de falsificación. Su código debe ser implacable: bloquee cualquier ejecución si el estado MEETS_BASIC_INTEGRITY Fracasa. No hay medias tintas, no hay modos degradados que dejen pasar a un atacante decidido.
En iOS, el reflejo se llama Certificado de aplicación. Este servicio ofrecido por Apple vincula criptográficamente su aplicación a su servidor. En concreto, proporciona un token que su back-end debe validar en cada llamada sensible. De este modo, se demuestra que es SU aplicación legítima la que envía la solicitud, y no una versión modificada o un clon malicioso.
Mantenga los secretos a salvo
En cuanto a los secretos de la aplicación, nunca deben salir de su caja fuerte física., Almacén de claves de Android y Llavero de iOS. No se limitan a cifrar sus claves y tokens, los vinculan al hardware del dispositivo. Esta vinculación hace que la extracción sea casi imposible sin un compromiso físico avanzado, lo que cambia por completo la ecuación para el atacante. Por lo tanto, nunca, jamás, almacene un secreto sin cifrar en su binario o en preferencias compartidas.
Maëlys, responsable de Android en una aplicación venta al por menor, da testimonio del impacto inmediato de estas medidas:
«Se sospechaba de clones de aplicaciones que llamaban a nuestros puntos finales sensibles. El día en que lo implementamos Certificado de aplicación lado iOS y Integridad en el juego En cuanto a Android, hemos cambiado las reglas del juego. El backend rechaza ahora cualquier crítica sin certificado válido, punto. En dos sprints, los intentos de fraude visibles en nuestros registros se han divididas por tres. Por parte del usuario, no ha cambiado nada: no se han añadido fricciones, solo un silencio de radio scripts que “bruteforceaban” nuestras API.
3e Pilar: la API blindada
La API es el lugar donde se gana o se pierde la seguridad móvil. Un token de acceso robado es, literalmente, las llaves del reino, el acceso total a la cuenta del usuario y a todos sus datos.
Si todavía utiliza el flujo implícito OAuth 2.0, está facilitando las cosas al atacante. El cambio a OAuth 2.1 con PKCE obligatorio no es una simple actualización cosmética, sino el cierre de una brecha enorme. Dado que la especificación OAuth 2.1 sigue siendo un borrador de Internet, lo esencial es aplicar estas medidas desde ya.
PKCE (Proof Key for Code Exchange) garantiza que, aunque un atacante intercepte el código de autorización durante la redirección, no podrá canjearlo por un token de acceso.
Es un primer paso sólido, pero solo resuelve una parte del problema.
¿Qué ocurre si el token de acceso final es robado posteriormente? ¿A través de un malware, una fuga en los registros, un XSS? Ahí es donde DPoP (Demonstration of Proof-of-Possession) entra en juego. Este mecanismo estandarizado, más fácil de implementar que mTLS en dispositivos móviles, cambia radicalmente las reglas del juego.
En concreto, con DPoP:
- El cliente móvil genera un par de claves locales.
- Él firma cada solicitud API con su clave privada (a través de un encabezado DPoP específico).
- El servidor valida la firma y comprueba que el token de acceso está vinculado a esta clave pública.
Resultado: un token de acceso robado se vuelve inútil. El atacante que no posee la clave privada de firma se queda con una simple cadena de caracteres sin ningún valor explotable. Es elegante, eficaz y cierra una puerta que muchas aplicaciones dejan abierta de par en par.
Por último, nunca descuides la capa de transporte. Exija como mínimo TLS 1.2 y prefiera TLS 1.3., elimine, elimine las suites de cifrado débiles (siguiendo las recomendaciones de la ANSSI o de Mozilla). Utilice HSTS (HTTP Strict Transport Security) para sus Interfaz Solo web para impedir ataques por retroceso a conexiones no seguras. Para las aplicaciones nativas, dé prioridad al certificado de fijación (Configuración de seguridad de red de Android, ATS de iOS) y una rotación planificada de las claves. Estas medidas son completamente invisibles para el usuario final... y cierran todas las puertas a los atacantes oportunistas.
Clara, SRE en un SaaS de RR. HH., resume bien el impacto:
«Se ha normalizado». TLS 1.3/HSTS en todo el parque. Para los clientes, no ha cambiado nada. Para nosotros, un montón de’alertas de ruido ha desaparecido y los escaneos externos por fin están limpios. Francamente, es una de las pocas medidas a un coste prácticamente nulo y alto impacto que se puede implementar rápidamente».»
Los dos ángulos muertos que pueden cambiarlo todo
Más allá de los tres pilares, a menudo persisten dos zonas oscuras en las estrategias de seguridad móvil. Se trata de ángulos muertos que, si se descuidan, pueden echar por tierra todos sus esfuerzos.
El primer punto ciego: su cadena de suministro, ese campo minado invisible
Hablemos con franqueza: ese SDK de análisis que integró hace dos años, ese módulo publicitario que le parecía tan práctico, pueden convertirse en un troyano de la noche a la mañana. Una vulnerabilidad descubierta en una dependencia de terceros, un SDK comprado por una empresa menos exigente en materia de seguridad, y toda su aplicación se vuelve vulnerable.
El primer paso consiste en saber exactamente lo que se embarca. Para ello, Genere sistemáticamente un SBOM., una lista de materiales de software, en formato CycloneDX en cada compilación.
Este inventario completo enumera todas sus dependencias directas y transitivas, creando un mapa preciso de su superficie de ataque.
Pero un inventario no es suficiente, hay que analizarlo. Aquí es donde entran en juego las herramientas SCA (Software Composition Analysis), que escanean su SBOM para detectar vulnerabilidades conocidas. Y, sobre todo, cuestione cada dependencia: ¿realmente necesita este SDK publicitario acceder a la red Y a los contactos del usuario? Documente estas decisiones y elimine sin piedad los accesos superfluos.
Louis, responsable de AppSec en un medio de comunicación, descubrió una ventaja inesperada de este enfoque:
«Cuando lanzamos nuestro primer SBOM CycloneDX propio, pensamos que ya estábamos tranquilos. Sin embargo, el escaneo SCA detectó un SDK público con permisos descabellados y un CVE reciente. Retiramos el SDK, implementamos un proceso de aprobación de dependencias y añadimos una revisión de los ámbitos en cada lanzamiento. Beneficio inesperado: el consumo de red disminuyó, al igual que el tiempo de arranque. No esperábamos esta mejora en el rendimiento y la seguridad».»
El segundo punto ciego: la ausencia de DevSecOps, o cómo posponer los problemas para mañana.
La seguridad probada al final del ciclo garantiza la detección de problemas críticos cuando ya es demasiado tarde para corregirlos adecuadamente. Por lo tanto, la seguridad debe convertirse en una condición para la construcción.
Para ello, automatice su ciclo de defensa. Inicie el análisis estático (SAST) y el análisis de dependencias (SCA) en cada confirmación. Integre herramientas como Semgrep o SonarQube para el código, Syft (generación SBOM) y Grype (escaneo de vulnerabilidades). ¿El objetivo? Romper la construir si un secreto es codificado de forma rígida o si se detecta una vulnerabilidad crítica. Sin tolerancia, sin «ya lo veremos más adelante».
A continuación, pase al binario propiamente dicho. Integre MobSF, el Mobile Security Framework, en su canalización de CI para auditar el APK o el IPA generado. Si no se respetan las configuraciones básicas del MASVS, la construir fracasa.
Añadir pruebas de API : verificaciones DPoP (nonce/jti/iat/htu/htm), detección de abusos/bots y rotación de tokens de actualización con detección de reutilización.
Por último, utilice sus pruebas de seguridad como herramienta.. Utilice Frida o Objeción para automatizar las verificaciones de’anti-manipulación. Si tus defensas contra el root/jailbreak o el Fijación SSL no reaccionan como se esperaba, la construir fracasa. Esta rigurosidad puede parecer brutal al principio, pero transforma radicalmente la calidad de lo que entregas.
Romain, DevSecOps en una empresa de tecnología educativa, da testimonio del cambio cultural:
«La primera vez que rompimos la compilación para una regresión MobSF, fue impopular. Dos días después, ya nadie discutía: las ganancias rápidas en seguridad salían antes de la producción, no después. Añadimos un informe semanal de controles, que se convirtió en un criterio de aceptación del producto. Además, el estrés en MEP se redujo: sabemos lo que entregamos».»
Su plan de acción: ¿por dónde empezar?
Ante esta lista de medidas, la parálisis acecha. ¿Por dónde empezar? ¿Cómo establecer prioridades? He aquí una trayectoria pragmática, dividida en tres fases de dos semanas cada una.
Semana 1-2: cartografíe lo existente
- Analice su aplicación con el MASVS v2
- Identifique sus 5 desviaciones críticas (las que más exponen a sus usuarios).
- Genere su primer SBOM CycloneDX con Syft y escanéelo con Grype.
Semana 3-4: implemente los cimientos
- Cliente : Play Integrity (Android) + App Attest (iOS)
- API : PKCE + DPoP en sus puntos finales sensibles (los que manejan datos críticos o transacciones financieras)
- Transporte : TLS 1.2 mínimo/1.3 preferido + certificate pinning (Configuración de seguridad de red de Android / ATS de iOS) (HSTS reservado para sus front-end web)
Semana 5-6: industrialice en el proceso CI/CD
- Integre SAST/SCA con la regla: cualquier vulnerabilidad crítica rompe la compilación
- Añadir MobSF para la auditoría de sus binarios
- Automatizar una prueba Frida sobre sus principales contramedidas + pruebas de API DPoP
El bar libre está cerrado... ¡para siempre!
La era en la que el móvil se consideraba un «simple cliente» ha llegado a su fin. Ahora es un punto final crítica. Las cifras de 2025 lo demuestran sin ambigüedad: los atacantes se dan un festín.
La certificación física, la autenticación reforzada y una CI implacable ya no están reservadas a las aplicaciones bancarias.
La seguridad ya no es una funcionalidad que se añade si el presupuesto lo permite. Es la base misma de la confianza que establece con sus usuarios. No espere a recibir un informe de auditoría catastrófico o a sufrir una violación de datos que le costará millones. Su nuevo mantra debe ser: « Si no es seguro, no entra en producción. "
Tu trabajo ya no consiste solo en entregar código que funcione. Consiste en generar confianza. Tu próximo comprometerse será su primera línea de defensa. Haga que valga la pena.
