OWASP Mobile Top 10: qué es, lista de vulnerabilidades y cómo aplicarlo

¿Qué es OWASP Mobile Top 10?

OWASP Mobile Top 10 es una lista estandarizada de los riesgos de seguridad más críticos específicos de las aplicaciones móviles. A diferencia del OWASP Top 10 general para aplicaciones web, la versión móvil tiene en cuenta las particularidades de las plataformas: almacenamiento local en el dispositivo, interacción con sensores, modos offline y peculiaridades de las tiendas de aplicaciones. El documento se publica desde 2010 y se revisa cada 2–4 años: la versión actual de 2024 incluye categorías como M1 — Improper Credential Usage y M8 — Security Misconfiguration. El proyecto cuenta con el apoyo de una comunidad de más de 500 voluntarios en todo el mundo.

Historia y propósito

Originalmente, OWASP Top 10 solo cubría aplicaciones web, pero el crecimiento del desarrollo móvil en la década de 2010 requirió un documento separado. La primera versión de Mobile Top 10 se lanzó en 2011 y contenía solo 7 elementos. Para 2024, la lista se amplió a 10 categorías, cada una incluyendo varios escenarios de ataque específicos. El propósito principal del documento es proporcionar a los desarrolladores y equipos de seguridad un lenguaje común para discutir riesgos y priorizar correcciones. Las actualizaciones periódicas de la lista reflejan cambios en el panorama de amenazas: la aparición de nuevas API, la evolución de los sistemas operativos (Android, iOS) y nuevas técnicas de ataque descritas en informes de Positive Technologies y otros centros de investigación.

Cómo se forma la lista OWASP Mobile Top 10

La metodología para compilar Mobile Top 10 se basa en datos de proyectos reales: se analizan resultados de pentests de aplicaciones móviles, informes de incidentes e investigaciones de vulnerabilidades. Cada categoría se evalúa según dos parámetros: tasa de incidencia (Incidence Rate) e impacto técnico (Technical Impact). La combinación de estas métricas forma la clasificación final. A diferencia de las listas subjetivas, OWASP utiliza datos abiertos: cualquier miembro de la comunidad puede enviar una solicitud para incluir una nueva categoría a través del repositorio de GitHub del proyecto. Para la versión actual de 2024, se procesaron más de 300 000 pruebas de seguridad de 25 países, lo que hace que las estadísticas sean representativas del ecosistema global de desarrollo móvil. Además, OWASP publica MASVS (Mobile Application Security Verification Standard), un conjunto de requisitos de seguridad detallados que incluye más de 80 verificaciones específicas distribuidas en 8 categorías. MASVS se utiliza como base para la certificación de aplicaciones y como lista de verificación para pentests: cada requisito tiene una referencia a una categoría de Mobile Top 10, lo que garantiza la trazabilidad entre el estándar y la lista de riesgos.

Resumen de las vulnerabilidades clave del top 10

Examinemos las tres categorías más críticas de OWASP Mobile Top 10 2024, que cubren más del 70% de todos los incidentes de seguridad en proyectos móviles. Cada categoría incluye escenarios de explotación específicos y recomendaciones de protección.

Uso incorrecto de la plataforma

Esta categoría (M1) cubre situaciones en las que los desarrolladores utilizan API y mecanismos de plataforma de forma incorrecta. Ejemplos típicos: Intent Injection en Android, manejadores de Deep Link abiertos en iOS, manejo incorrecto de Keychain y SharedPreferences. Un atacante puede enviar un Intent especialmente diseñado y obtener acceso a datos de otra aplicación o componente. Según el informe de NowSecure (2023), el 22% de las aplicaciones Android probadas contenían vulnerabilidades de tipo Intent Redirection. La protección incluye: validación estricta de datos de entrada, verificación del origen del Intent y uso de permisos para componentes exportados.

Almacenamiento inseguro de datos

Almacenamiento inseguro de datos (M2) es el problema más común en las aplicaciones móviles. Ocurre cuando los datos confidenciales (tokens de acceso, contraseñas, datos personales) se almacenan en texto plano o con protección insuficiente. Fuentes típicas de vulnerabilidad: bases de datos SQLite sin cifrado, SharedPreferences sin EncryptedSharedPreferences, registro de datos en modo debug. Según OWASP Foundation (2024), más del 60% de las aplicaciones gratuitas en Google Play almacenan al menos un tipo de datos confidenciales sin cifrar. La solución es usar Android EncryptedSharedPreferences, iOS Keychain y cifrar los datos antes de escribirlos en el almacenamiento local.

Comunicación insegura

La categoría M3 — Comunicación insegura — incluye vulnerabilidades en los canales de transmisión de datos entre la aplicación y el servidor. La falta de HTTPS, la validación incorrecta de certificados SSL, el uso de protocolos TLS 1.0/1.1 obsoletos — todos estos problemas permiten que un atacante intercepte el tráfico mediante ataques Man-in-the-Middle. La situación es especialmente peligrosa cuando la aplicación trabaja con datos sensibles (transacciones bancarias, información médica) a través de un canal no protegido. En 2023, investigadores de NCC Group descubrieron que el 12% de las aplicaciones financieras populares utilizan una configuración TLS incorrecta. Recomendación: uso obligatorio de HTTPS con Certificate Pinning y rechazo de HTTP en compilaciones de producción.

Cómo probar aplicaciones según OWASP Mobile Top 10

Las pruebas de seguridad de una aplicación móvil según la metodología OWASP incluyen varias etapas: análisis estático de código (SAST), análisis dinámico (DAST) y pruebas manuales (pentest). Cada etapa está orientada a identificar categorías específicas de vulnerabilidades de Mobile Top 10.

Herramientas de prueba

Para el análisis automatizado, OWASP recomienda usar MobSF (Mobile Security Framework), una herramienta de código abierto. MobSF realiza análisis estático de código fuente y archivos binarios, verifica la configuración del manifiesto, analiza permisos e identifica vulnerabilidades de Mobile Top 10. Para el análisis dinámico se utilizan Burp Suite (proxy para interceptación de tráfico) y Frida (herramienta de análisis en tiempo de ejecución). La combinación de estas herramientas cubre más del 80% de las categorías de la lista. Las pruebas regulares en un pipeline CI/CD con MobSF permiten identificar vulnerabilidades en etapas tempranas del desarrollo y reducen el costo de corregirlas en un 60–70%. La integración de herramientas SAST y DAST en el pipeline debe automatizarse mediante plugins de Gradle/Maven o pasos de Fastlane en compilaciones de iOS.

Interpretación del informe MobSF

Después de ejecutar MobSF, el desarrollador recibe un informe con indicadores de color: rojo — vulnerabilidad crítica, naranja — riesgo medio, amarillo — riesgo bajo. Cada advertencia contiene una referencia a la categoría correspondiente de OWASP Mobile Top 10, una descripción del problema y una recomendación de corrección. Es importante no solo eliminar las advertencias rojas, sino también analizar las naranjas: muchas de ellas (por ejemplo, Activities exportadas sin protección) pueden combinarse para dar al atacante un vector de ataque. Se recomienda lograr cero advertencias rojas y no más de 2–3 naranjas antes de cada lanzamiento. El informe de MobSF también incluye un análisis de los permisos de la aplicación: cualquier permiso excesivo (por ejemplo, acceso a la cámara en una calculadora) se marca como una violación del principio de mínimo privilegio y debe eliminarse del manifiesto. Para aplicaciones iOS, MobSF realiza un análisis similar de archivos .ipa, incluyendo la verificación de Info.plist para excepciones ATS y el análisis de binarios Mach-O para API inseguras como NSAllowsArbitraryLoads.

class InsecureStorage {
    private val prefs = context.getSharedPreferences("my_app", Context.MODE_PRIVATE)

    fun saveToken(token: String) {
        prefs.edit().putString("auth_token", token).apply()
    }

    fun getToken(): String? {
        return prefs.getString("auth_token", null)
    }
}

class SecureStorage(context: Context) {
    private val masterKey = MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build()

    private val securePrefs = EncryptedSharedPreferences.create(
        context,
        "secure_prefs",
        masterKey,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun saveToken(token: String) {
        securePrefs.edit().putString("auth_token", token).apply()
    }
}