Seguridad al desarrollar apps para Android: 6 riesgos y cómo evitarlos

Android sigue siendo el sistema operativo móvil con más usuarios del mundo, y eso lo convierte en el objetivo favorito de quien quiere robar datos, suplantar una app o colar malware. Para una empresa, desarrollar apps para Android con la seguridad bien resuelta ya no es opcional: Google endurece cada año los requisitos de Google Play y del propio sistema, y una brecha en una app corporativa expone datos de clientes, credenciales y la reputación de la marca.

En este artículo repasamos los seis riesgos de seguridad que más se repiten al desarrollar apps para Android en 2026, qué ha cambiado en las últimas versiones del sistema y cómo comprobar que tu app está bien protegida antes de publicarla. Todas las referencias técnicas enlazan a la documentación oficial de Android Developers y al estándar de seguridad móvil de OWASP MAS.

Índice

• 1. Datos sensibles guardados sin protección en el dispositivo
• 2. Comunicaciones inseguras con el servidor
• 3. Pedir más permisos de los necesarios
• 4. Componentes expuestos a otras apps
• 5. Apps modificadas, clonadas o ejecutadas en dispositivos comprometidos
• 6. Librerías de terceros y versiones objetivo desactualizadas
• Cómo comprobar la seguridad antes de publicar: OWASP MASVS y MASTG
• Desarrollar apps para Android seguras con Yeeply

1. Datos sensibles guardados sin protección en el dispositivo

Es el fallo más común en las auditorías de apps móviles: tokens de sesión, datos personales o claves de API guardados en texto plano en las preferencias compartidas, en una base de datos SQLite o en ficheros dentro del almacenamiento de la app. En un móvil rooteado, o con una copia de seguridad mal configurada, esa información queda al alcance de cualquiera.

Qué hacer:

• No guardes en el dispositivo nada que no necesites. Lo más seguro es lo que no está.
• Usa el Android Keystore para generar y custodiar las claves criptográficas, de forma que no se puedan extraer del dispositivo.
• Si usabas la librería Jetpack Security (EncryptedSharedPreferences), ten en cuenta que Google marcó como obsoletas todas sus API en 2025 y recomienda usar directamente las API de la plataforma y el Keystore. Conviene planificar la migración.
• Excluye de las copias de seguridad automáticas los ficheros con datos sensibles.

OWASP agrupa estos controles en las categorías MASVS-STORAGE y MASVS-CRYPTO de su estándar de verificación.

2. Comunicaciones inseguras con el servidor

Desde Android 9 (API 28), el tráfico en texto claro (HTTP sin cifrar) está desactivado por defecto. Aun así, sigue apareciendo en auditorías porque alguien lo reactivó para un entorno de pruebas y se quedó así en producción, o porque la app acepta cualquier certificado para «evitar errores».

• Revisa el fichero de configuración de seguridad de red y no permitas cleartext salvo en dominios concretos y justificados.
• Nunca desactives la validación de certificados TLS en el código.
• Si la app maneja datos muy sensibles (banca, salud), valora el certificate pinning. La documentación oficial insiste en incluir siempre una clave de respaldo: sin ella, un cambio de certificado en el servidor deja la app sin conexión hasta que publiques una actualización.

3. Pedir más permisos de los necesarios

Cada permiso que pide una app es una puerta más. Y desde hace varias versiones, Android empuja a pedir lo mínimo:

• Para que el usuario elija fotos o vídeos, el selector de fotos del sistema no necesita ningún permiso de almacenamiento.
• Desde Android 14, el usuario puede dar acceso solo a las fotos que elija en lugar de a toda la galería. Si tu app tiene su propia galería, debe gestionar el permiso READ_MEDIA_VISUAL_USER_SELECTED.
• Pide cada permiso en el momento en que se usa, explicando para qué, y comprueba siempre si sigue concedido: el usuario puede retirarlo desde Ajustes en cualquier momento.

Los permisos también cuentan en Google Play: la ficha de la app incluye una sección de seguridad de los datos que debe declarar qué datos se recogen y con quién se comparten. Tienes más detalle sobre este tema en nuestro artículo sobre permisos de acceso en apps móviles.

4. Componentes expuestos a otras apps

Actividades, servicios, receptores de difusión y proveedores de contenido pueden quedar accesibles para otras apps del dispositivo. Si uno de ellos está expuesto sin querer, una app maliciosa puede abrir pantallas internas, lanzar acciones o leer datos.

• Desde Android 12, cualquier componente con intent filter debe declarar explícitamente android:exported. Ponlo a false salvo que otra app tenga que invocarlo.
• Declara la mutabilidad de cada PendingIntent y usa FLAG_IMMUTABLE siempre que puedas, como explica la guía de riesgos de PendingIntent.
• Valida todo lo que llega por un intent o un enlace profundo como si viniera de un desconocido, porque puede venir de uno.

5. Apps modificadas, clonadas o ejecutadas en dispositivos comprometidos

Un atacante puede descompilar tu APK, quitarle comprobaciones, añadirle código malicioso y redistribuirla fuera de Google Play con tu nombre y tu icono. También puede ejecutar la app original en un dispositivo rooteado o en un emulador para saltarse controles.

• Usa la API Play Integrity para que tu servidor compruebe que la petición viene de tu app sin modificar, instalada desde Google Play y en un dispositivo fiable. Sustituye a SafetyNet Attestation, que dejó de funcionar en enero de 2025: si tu app todavía la llama, esa comprobación ya está fallando.
• Ofusca y minimiza el código en las versiones de producción, y no dejes secretos dentro del APK: todo lo que va en la app se puede extraer.
• Repite en el servidor las validaciones importantes que haga el cliente: la app se puede manipular, el servidor no.

Google también está cerrando el paso a las apps de origen desconocido. Android 14 y Android 15 ya impiden instalar apps cuya versión objetivo sea anterior a la API 23 y a la API 24, respectivamente, un truco habitual del malware para esquivar protecciones. Y con la verificación de desarrolladores, que arrancó el 30 de septiembre de 2026 en Brasil, Indonesia, Singapur y Tailandia y se extenderá a todo el mundo en 2027, las apps instaladas en dispositivos certificados tendrán que venir de un desarrollador con identidad verificada.

6. Librerías de terceros y versiones objetivo desactualizadas

Una app moderna lleva decenas de librerías y SDK: analítica, pagos, publicidad, mapas. Cada uno es código que no has escrito y que puede tener vulnerabilidades o recoger datos sin que lo sepas.

• Mantén un inventario de dependencias y revisa sus vulnerabilidades conocidas en cada versión, con herramientas como OWASP Dependency-Check o las que integre tu plataforma de integración continua.
• Elimina los SDK que ya no uses.
• Sigue los boletines de seguridad de Android para saber qué fallos del sistema afectan a tus usuarios.

La versión objetivo también es un requisito de seguridad. Desde el 31 de agosto de 2026, Google Play exige que las apps nuevas y las actualizaciones apunten a Android 16 (API 36), y las apps existentes que se queden por debajo de Android 15 (API 35) dejan de estar disponibles para nuevos usuarios con versiones más recientes del sistema. Se puede pedir una prórroga hasta el 1 de noviembre de 2026, pero no más.

Cómo comprobar la seguridad antes de publicar: OWASP MASVS y MASTG

La referencia del sector para la seguridad de apps móviles es el proyecto OWASP Mobile Application Security, que tiene dos piezas:

• MASVS, el estándar de verificación, que define qué debe cumplir una app en ocho grupos de controles: almacenamiento, criptografía, autenticación, red, interacción con la plataforma, calidad del código, resiliencia frente a manipulación y privacidad.
• MASTG, la guía de pruebas, que explica cómo comprobar cada uno de esos controles en Android y en iOS.

Lo práctico es usar MASVS como lista de requisitos desde el diseño, para que el equipo sepa qué tiene que cumplir, y encargar un pentest móvil con MASTG antes de lanzar la app y después de cada cambio importante. Un pentest de app móvil en España cuesta entre 3.000 y 10.000 euros según la complejidad; tienes el desglose en nuestra guía de precios de pentesting.

Si encargas el desarrollo a una empresa externa, pide que el contrato o la propuesta incluyan al menos estos puntos:

• El nivel de MASVS que se va a cumplir y quién lo verifica.
• Un inventario de librerías y SDK de terceros, con su versión, que se actualice en cada entrega.
• La integración de Play Integrity en las operaciones sensibles (inicio de sesión, pagos, cambios de datos personales).
• Un pentest móvil antes del lanzamiento, con retest de lo que se corrija.
• Un plan de mantenimiento que cubra el cambio anual de versión objetivo que exige Google Play y los parches de seguridad de las librerías.

Con eso por escrito, la seguridad deja de depender de la buena voluntad de cada desarrollador y pasa a ser un entregable que se puede revisar.

Si estás empezando, el checklist del creador de apps ideal te ayuda a ordenar el proyecto antes de escribir código.

Desarrollar apps para Android seguras con Yeeply

En Yeeply trabajamos con empresas certificadas de desarrollo de aplicaciones móviles que aplican estos controles desde el diseño, y con empresas especializadas en ciberseguridad que auditan apps ya publicadas. Te presentamos propuestas comparables y supervisamos el proyecto hasta la entrega.

Si quieres desarrollar apps para Android o revisar la seguridad de la que ya tienes, pulsa «Solicitar presupuesto» arriba a la derecha o escríbenos a sales@yeeply.com.