Repasemos el OWASP Mobile Top 10: ¿cuáles importan más en una app de consumo típica?
La lista no está ordenada por severidad: lo senior es mapear sus diez categorías a los datos reales y al atacante real de tu propia app.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
Repasemos el OWASP Mobile Top 10: ¿cuáles importan más en una app de consumo típica?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Qué es realmente la lista
El OWASP Mobile Top 10 es una categorización de las áreas de riesgo móvil más comunes, actualizada por el equipo de OWASP Mobile Security para reflejar cómo se construyen y atacan las apps hoy en día — con más peso en riesgos cercanos al backend (autenticación, cadena de suministro, privacidad) que la edición original de 2016, más centrada en la calidad del código del lado cliente. Explícitamente no está ordenada por severidad: M1 no es "peor" que M10 para toda app, simplemente aparece primero en la numeración actual. Los entrevistadores que te piden "repasarla" rara vez están probando que memorizaste la redacción exacta — están probando si puedes usarla como checklist para estructurar una conversación de threat modeling y luego razonar sobre qué categorías realmente muerden en la app que tienes enfrente.
Aquí está el conjunto actual, en una frase cada una:
- M1 — Uso indebido de credenciales. Secretos hardcodeados, tokens guardados de forma insegura o vivos mucho más tiempo del necesario, y mal manejo de las credenciales que una app recolecta o reenvía.
- M2 — Seguridad inadecuada de la cadena de suministro. Riesgo introducido por SDKs de terceros, herramientas de build y dependencias que tú no escribiste — un SDK de analítica comprometido cae en esta categoría.
- M3 — Autenticación/autorización insegura. Checks solo del lado cliente, manejo débil de sesiones, y huecos de autorización en el backend (tipo IDOR) que la superficie de API móvil termina exponiendo.
- M4 — Validación insuficiente de entrada/salida. Confiar en datos de la red, deep links, intents o el portapapeles sin validarlos antes de actuar sobre ellos.
- M5 — Comunicación insegura. Tráfico en texto plano, validación de certificados desactivada o degradada, y SDKs de terceros que llaman a casa por HTTP simple.
- M6 — Controles de privacidad inadecuados. Recolectar, retener o compartir más datos personales de los que la funcionalidad necesita, o sin el consentimiento que exige la plataforma (y la regulación).
- M7 — Protecciones binarias insuficientes. Poca resistencia a la ingeniería inversa, la manipulación y el re-empaquetado del binario cliente mismo.
- M8 — Configuración de seguridad incorrecta. Builds de release depurables, componentes exportados sin checks de permisos, mensajes de error verbosos, reglas de backup demasiado permisivas.
- M9 — Almacenamiento de datos inseguro. Tokens, PII o respuestas cacheadas sentadas sin cifrar en shared preferences,
UserDefaults, logs o backups. - M10 — Criptografía insuficiente. Algoritmos débiles, criptografía casera, o algoritmos correctos usados incorrectamente (IVs reutilizados, modo ECB, claves derivadas de material predecible).
#Cuáles importan realmente en una app de consumo típica
No las diez pesan igual para, digamos, una app social o de e-commerce sin manejo de tarjetas de pago ni preocupaciones de DRM. En orden aproximado de qué tan seguido aparecen:
M9 (Almacenamiento de datos inseguro) es casi universal — casi toda app persiste un token de sesión, algún dato de usuario cacheado, o migas de reportes de crash, y SharedPreferences/UserDefaults en texto plano sigue siendo la forma más común en que esos datos se filtran en un dispositivo perdido o compartido. M5 (Comunicación insegura) le sigue de cerca: tráfico en texto plano que quedó de un build de depuración, o un atajo de validación de certificado agregado "temporalmente" para un entorno de staging y nunca retirado, son hallazgos extremadamente comunes. M1 (Uso indebido de credenciales) aparece constantemente como API keys hardcodeadas en el cliente y tokens que nunca expiran. M3 (Autenticación/autorización insegura) importa en cuanto una app tiene más que una pantalla de login — la mayor parte del daño real suele vivir en el backend con el que habla el cliente móvil, pero la app móvil suele ser por dónde se descubre el hueco. Y M2 (Seguridad inadecuada de la cadena de suministro) merece más atención de la que normalmente recibe: una app de consumo típica embebe más de una docena de SDKs de publicidad, analítica y reportes de crash, cada uno una dependencia que no auditaste y un vector que no controlas del todo.
En cambio, M7 (Protecciones binarias insuficientes) y M10 (Criptografía insuficiente) importan enormemente para una app bancaria, un reproductor de video con DRM, o un sistema anti-cheat, y mucho menos para una app de lista de tareas que no tiene lógica del lado cliente que valga la pena manipular. M6 (Controles de privacidad inadecuados) queda en un punto intermedio — cada vez más se le impone a toda app sin importar el modelo de amenaza por App Tracking Transparency, las etiquetas de Data Safety de Play, y GDPR/CCPA, así que aparece como requisito de cumplimiento incluso donde no es un objetivo de ataque jugoso.
#Cómo responder esto de verdad en una entrevista
La respuesta débil recita las diez por igual, como si fueran igual de probables y de graves para cualquier app. La respuesta fuerte elige tres o cuatro, las ata explícitamente a un mecanismo concreto ("M9 porque nuestro refresh token vivía en SharedPreferences en claro hasta que lo movimos detrás de EncryptedSharedPreferences", no solo "el almacenamiento inseguro es malo"), y explica por qué esas quedan por encima del resto para la sensibilidad de datos y la motivación del atacante de esta app en concreto. Es la misma habilidad que leer una base de código y saber qué anti-patrón merece un comentario en el PR frente a cuál es solo ruido de estilo — priorizar bajo un modelo de amenaza, no recitar categorías.
🧠 OWASP Mobile Top 10
0/3 · 0/3 answered1. ¿El OWASP Mobile Top 10 está ordenado por severidad, de más a menos crítico?
2. Para una app de consumo típica (no bancaria ni de DRM), ¿qué pareja es la más inmediatamente relevante?
3. Un SDK de analítica de terceros que tu app embebe se ve comprometido en su origen y empieza a exfiltrar datos. ¿Qué categoría captura mejor este riesgo antes de que ocurra?