OWASP MAS (Mobile Application Security) es el proyecto de OWASP dedicado a la seguridad de aplicaciones móviles. Su objetivo es convertir una auditoría Android o iOS en un proceso sistemático y reproducible: MASVS define qué debe cumplir la aplicación, MASWE describe las debilidades que pueden romper esos requisitos y MASTG explica cómo verificarlas mediante pruebas técnicas.
Si buscas una referencia para pentesting móvil, revisión de seguridad, desarrollo seguro o validación de una app antes de producción, OWASP MAS es uno de los mejores puntos de partida. En esta guía veremos cómo encajan MASVS, MASWE y MASTG, qué cambió en 2026, cómo aplicarlos en una auditoría real y qué herramientas se utilizan.
En esta guía
- Qué es OWASP MAS
- MASVS, MASWE y MASTG: qué diferencia hay
- Qué cambió en OWASP MAS en 2026
- Las 8 categorías de OWASP MASVS
- Cómo usar OWASP MAS en una auditoría móvil
- Ejemplos de vulnerabilidades por categoría
- Herramientas para mobile security testing
- Android vs iOS
- Qué pasó con OWASP MAS Checklist
- OWASP MAS en pentesting y bug bounty
- Cómo empezar con OWASP MAS
- Preguntas frecuentes
Qué es OWASP MAS
OWASP Mobile Application Security (MAS) es el proyecto de OWASP centrado en la seguridad de aplicaciones móviles. No es una herramienta ni una certificación. Es un conjunto de estándares y recursos abiertos que ayudan a desarrolladores, arquitectos y auditores a evaluar la seguridad de aplicaciones Android e iOS de forma consistente.
Su recurso central es OWASP MASVS (Mobile Application Security Verification Standard), considerado por OWASP el estándar de la industria para seguridad de aplicaciones móviles. MASVS organiza los controles que una aplicación debería cumplir en áreas como almacenamiento, criptografía, autenticación, red, plataforma, código, resiliencia y privacidad.
Sin embargo, un control de alto nivel no siempre indica exactamente qué fallo buscar o cómo comprobarlo. Ahí entran MASWE y MASTG.
Esta cadena es la forma más útil de entender el proyecto actualmente: empiezas por el requisito de seguridad, identificas las debilidades asociadas y terminas en pruebas concretas y reproducibles.
MASVS, MASWE y MASTG: qué diferencia hay
MASVS: el estándar, el “qué”
MASVS define los requisitos de seguridad. Por ejemplo, MASVS-STORAGE-1 establece que la aplicación debe almacenar los datos sensibles de forma segura. Su función no es darte un comando concreto, sino definir el objetivo que debe cumplir la app.
MASWE: las debilidades, el “por qué puede fallar”
MASWE (Mobile Application Security Weakness Enumeration) cataloga debilidades específicas de aplicaciones móviles. Actúa como puente entre los controles de MASVS y las pruebas de MASTG.
Por ejemplo, dentro de almacenamiento aparecen debilidades como datos sensibles sin cifrar en almacenamiento privado, claves criptográficas fuera del keystore de la plataforma, secretos incluidos en el paquete de la app o información sensible escrita en logs.
MASTG: la guía de testing, el “cómo”
MASTG (Mobile Application Security Testing Guide) proporciona conocimiento técnico, técnicas, herramientas, pruebas y demos para Android e iOS. Es la capa que traduce el estándar a trabajo de auditoría.
Con MASTG v2 la trazabilidad es mucho más clara: cada test puede vincularse con una debilidad MASWE concreta y, desde ella, con el control MASVS correspondiente.
Qué cambió en OWASP MAS en 2026
Si has leído documentación antigua, es importante tener en cuenta tres cambios recientes:
- MASTG v2.0.0: publicado en junio de 2026, reorganiza la guía en un modelo modular y enlaza las pruebas con debilidades MASWE.
- MASWE v1.0.0: publicado en agosto de 2026, establece 78 debilidades estables, completamente documentadas y numeradas.
- MAS Checklist: el spreadsheet generado que acompañaba versiones anteriores ya no se distribuye como artefacto oficial de MASTG v2.
También conviene evitar documentación que siga hablando de los antiguos niveles MASVS L1, L2 y R como si continuaran formando parte del estándar actual. Desde MASVS 2.0 dejaron de ser “verification levels” del estándar y el proyecto está evolucionando hacia MAS Testing Profiles.
Las 8 categorías de OWASP MASVS
MASVS divide la superficie de seguridad móvil en ocho grupos de controles:
| Categoría | Qué cubre |
|---|---|
MASVS-STORAGE | Almacenamiento seguro y prevención de fugas de datos sensibles en el dispositivo. |
MASVS-CRYPTO | Uso correcto de criptografía, algoritmos y material criptográfico. |
MASVS-AUTH | Autenticación y autorización implementadas por la aplicación móvil. |
MASVS-NETWORK | Protección de las comunicaciones entre la app y endpoints remotos. |
MASVS-PLATFORM | Interacción segura con el sistema operativo y con otras aplicaciones. |
MASVS-CODE | Procesamiento seguro de datos, actualización de componentes y buenas prácticas de código. |
MASVS-RESILIENCE | Resistencia frente a ingeniería inversa y manipulación. |
MASVS-PRIVACY | Controles relacionados con la privacidad del usuario. |
Estas categorías sirven como mapa de cobertura. No significan que todas las aplicaciones necesiten exactamente las mismas pruebas: el alcance debe adaptarse al riesgo, funcionalidades, datos tratados y modelo de amenazas de cada app.
Cómo usar OWASP MAS en una auditoría móvil
El error típico al empezar en mobile pentesting es abrir jadx, Burp o Frida y buscar “cosas raras” sin un criterio de cobertura. OWASP MAS permite trabajar al revés: primero defines qué quieres verificar y después seleccionas las pruebas adecuadas.
- Define el alcance y modelo de amenazas. Qué versión de Android/iOS se prueba, qué funcionalidades están incluidas, qué datos maneja la app y qué escenarios son relevantes.
- Selecciona los controles MASVS. Úsalos como referencia de los objetivos de seguridad que quieres cubrir.
- Consulta MASWE. Identifica qué debilidades pueden provocar que cada control falle.
- Selecciona pruebas MASTG. Ejecuta las técnicas correspondientes sobre la plataforma y versión objetivo.
- Documenta evidencia e impacto. Registra condición vulnerable, pasos de reproducción, evidencia, riesgo y recomendación.
Ejemplo: MASVS-STORAGE-1
Supongamos que queremos verificar que una aplicación almacena correctamente información sensible. En vez de limitar la auditoría a “buscar SharedPreferences”, revisamos las debilidades asociadas al control y elegimos las pruebas aplicables.
# Aplicación propia / laboratorio $ adb shell $ run-as com.example.demo $ find . -type f | head # Revisar preferencias y bases de datos $ cat shared_prefs/auth.xml $ find . -name "*.db" -o -name "*.sqlite"
Si encontramos un token de sesión persistente en claro, el valor de OWASP MAS no está en el comando: está en poder relacionar la evidencia con la debilidad correspondiente y con el control MASVS que pretendíamos verificar.
Ejemplos de vulnerabilidades por categoría
MASVS-STORAGE: datos sensibles almacenados de forma insegura
# Buscar datos sensibles en preferencias de una app de laboratorio $ grep -RniE "token|password|secret|api[_-]?key" shared_prefs/ files/ databases/ 2>/dev/null
Fallos frecuentes: tokens en texto claro, datos personales en logs, claves dentro del APK/IPA, backups que incluyen información sensible o ficheros almacenados en ubicaciones inadecuadas.
MASVS-CRYPTO: criptografía débil o mal utilizada
# Búsqueda estática tras descompilar una APK propia $ grep -RniE 'DES|AES/ECB|MD5|SecretKeySpec' ./sources/
El objetivo no es simplemente encontrar una cadena como “AES”, sino comprobar si el algoritmo, modo de operación, generación de claves, almacenamiento y ciclo de vida del material criptográfico son apropiados.
MASVS-AUTH: decisiones de seguridad en el cliente
Un patrón crítico aparece cuando la aplicación toma localmente una decisión que debería validarse en servidor: autorización de operaciones, estado premium, acceso a información de otra cuenta o validez de una sesión.
MASVS-NETWORK: comunicaciones inseguras
# Android: revisar Network Security Config $ grep -Rni "cleartextTrafficPermitted" ./res ./AndroidManifest.xml
La auditoría debe revisar TLS, confianza de certificados, configuración de red, tráfico en claro y las medidas adicionales que la aplicación utilice para proteger comunicaciones sensibles.
MASVS-PLATFORM: WebViews, deep links e IPC
# Revisar componentes exportados y deep links $ grep -RniE 'exported="true"|android:scheme|android:host' AndroidManifest.xml
Aquí se analizan componentes específicos de la plataforma: intents, activities, content providers, WebViews y deep links en Android; URL schemes, Universal Links, entitlements y mecanismos equivalentes en iOS.
MASVS-CODE: dependencias y procesamiento inseguro
Incluye dependencias vulnerables u obsoletas, validaciones incorrectas, exposición de funcionalidades de depuración y otros problemas relacionados con la forma en que la aplicación procesa datos y mantiene actualizado su código.
MASVS-RESILIENCE: ingeniería inversa y manipulación
Evalúa controles frente a modificación, instrumentación, debugging, hooking y análisis del binario. La necesidad y profundidad de estas medidas depende del modelo de amenazas: no todas las aplicaciones requieren el mismo nivel de resiliencia.
MASVS-PRIVACY: privacidad del usuario
Revisa qué información personal maneja la app, qué permisos solicita, qué datos recopila o comparte y si existen mecanismos que permitan al usuario ejercer el control esperado sobre su privacidad.
Herramientas para mobile security testing con OWASP MAS
| Herramienta | Plataforma | Uso habitual |
|---|---|---|
| Frida | Android / iOS | Instrumentación dinámica y observación del comportamiento en ejecución. |
| Objection | Android / iOS | Exploración e instrumentación apoyada en Frida. |
| jadx | Android | Análisis estático y revisión de código descompilado. |
| apktool | Android | Inspección de recursos, manifiesto y bytecode Smali. |
| MobSF | Android / iOS | Análisis automatizado como apoyo inicial, no como sustituto de la revisión manual. |
| Burp Suite | Android / iOS | Análisis del tráfico HTTP/S y de las APIs backend consumidas por la app. |
| adb | Android | Interacción con dispositivo/emulador, instalación, logs y sistema de ficheros. |
| Ghidra / IDA | Android / iOS | Ingeniería inversa de código nativo. |
Android e iOS: mismo estándar, distinta superficie
| Área | Android | iOS |
|---|---|---|
| Paquete | APK / AAB | IPA |
| Almacenamiento | SharedPreferences, SQLite, Keystore, ficheros internos/externos | Keychain, UserDefaults, Core Data, Data Protection |
| Análisis estático | jadx, apktool, Ghidra | otool, class-dump según caso, Ghidra/IDA y herramientas específicas |
| Instrumentación | Frida/Objection sobre dispositivo o entorno de pruebas compatible | Frida/Objection sobre dispositivo de pruebas compatible |
| Superficie de plataforma | Activities, Services, Providers, Receivers, intents y App Links | URL schemes, Universal Links, extensions y entitlements |
El estándar es común; la implementación de las pruebas no. Un auditor debe traducir cada objetivo MASVS a los mecanismos reales de Android o iOS.
Qué pasó con OWASP MAS Checklist
“OWASP MAS Checklist” sigue apareciendo en muchas búsquedas y documentación antigua, pero el proyecto cambió en 2026. Las versiones anteriores de MASTG generaban un spreadsheet que permitía recorrer controles MASVS y pruebas asociadas. Con MASTG v2.0.0, ese spreadsheet dejó de distribuirse como artefacto oficial.
Esto no significa que haya desaparecido la necesidad de controlar cobertura. Lo que cambia es el modelo:
En una auditoría profesional puedes mantener tu propia matriz de cobertura —por ejemplo en una hoja de cálculo, herramienta GRC o sistema de reporting— utilizando como identificadores los controles MASVS, debilidades MASWE y tests MASTG aplicables.
OWASP MAS en pentesting y bug bounty
Mapear un hallazgo a OWASP MAS no sustituye el análisis de impacto, pero mejora mucho la reproducibilidad del informe. Permite explicar qué objetivo de seguridad falla, qué debilidad concreta existe y cómo se ha demostrado.
| Parte del reporte | Ejemplo |
|---|---|
| Hallazgo | Token de sesión persistente almacenado en claro. |
| Referencia | Control MASVS y debilidad MASWE aplicables. |
| Evidencia | Ruta, valor observado y pasos reproducibles en el entorno autorizado. |
| Impacto | Qué puede hacer realmente un atacante dadas las precondiciones necesarias. |
| Solución | Corrección técnica y validación posterior. |
En bug bounty, la severidad y elegibilidad dependen de las reglas del programa y del impacto real. La ausencia de certificate pinning, la detección de root o una configuración concreta no deben asumirse automáticamente como vulnerabilidades pagables: hay que demostrar una consecuencia de seguridad dentro del alcance.
Cómo empezar con OWASP MAS
- Lee primero los ocho grupos de controles de MASVS para entender el mapa completo.
- Elige una categoría sencilla, como
MASVS-STORAGE. - Consulta las debilidades MASWE asociadas.
- Localiza en MASTG las pruebas aplicables a Android o iOS.
- Practica sobre una app deliberadamente vulnerable, propia o de laboratorio.
- Documenta cada prueba y resultado como si fuera una auditoría profesional.
Si vienes de seguridad web, buena parte del conocimiento sigue siendo útil porque las apps móviles consumen APIs y backends donde siguen existiendo IDOR/BOLA, autenticación rota, lógica de negocio, SSRF o fallos de autorización. La diferencia es que ahora también debes analizar el cliente móvil, su almacenamiento, plataforma y comportamiento en ejecución.
¿Quieres aprender mobile pentesting de forma estructurada?
En Mobile eXploitation Specialist (MXS) trabajamos análisis de aplicaciones móviles, Android e iOS, instrumentación, ingeniería inversa y seguridad de APIs con metodología práctica. Si antes quieres reforzar explotación web y APIs, puedes consultar Web eXploitation Expert (WXE).
Preguntas frecuentes sobre OWASP MAS, MASVS y MASTG
¿Qué es OWASP MAS?
Es el proyecto de OWASP dedicado a la seguridad de aplicaciones móviles. Incluye recursos como MASVS, MASWE y MASTG para definir requisitos, clasificar debilidades y realizar pruebas de seguridad en Android e iOS.
¿Qué es OWASP MASVS?
OWASP MASVS es el Mobile Application Security Verification Standard, el estándar que define controles de seguridad para aplicaciones móviles en ocho áreas: storage, crypto, auth, network, platform, code, resilience y privacy.
¿Cuál es la diferencia entre MASVS, MASWE y MASTG?
MASVS define qué debe cumplir la app; MASWE describe qué debilidades pueden romper esos requisitos; y MASTG explica cómo comprobarlas mediante conocimiento, técnicas y pruebas.
¿Qué es MASVS-STORAGE-1?
Es uno de los controles de almacenamiento de MASVS. Su objetivo es que la aplicación almacene los datos sensibles de forma segura. Para probarlo correctamente hay que revisar las debilidades MASWE y tests MASTG asociados que sean aplicables al entorno.
¿Sigue existiendo OWASP MAS Checklist?
El spreadsheet que se distribuía con versiones anteriores dejó de formar parte de MASTG v2 como artefacto oficial. La cobertura se articula ahora alrededor de la trazabilidad MASVS → MASWE → MASTG, aunque un equipo puede mantener su propia matriz de seguimiento.
¿OWASP MAS sirve para Android e iOS?
Sí. MASVS proporciona un marco común y MASTG contiene conocimiento y pruebas específicas para ambas plataformas.
¿OWASP MAS es una certificación?
No. Es un proyecto abierto de OWASP y un marco de referencia para seguridad móvil. No es un examen ni una certificación profesional.
¿Necesito saber hacking web para aprender mobile pentesting?
No es obligatorio, pero ayuda mucho. Las apps móviles dependen de APIs y servicios backend, por lo que conocer autenticación, autorización, HTTP y vulnerabilidades web permite analizar no solo el cliente móvil sino el sistema completo.