Seguridad en aplicaciones móviles: normativa, riesgos y coste

La seguridad en aplicaciones móviles ha dejado de ser una conversación de ingeniería para convertirse en una de calendario regulatorio. Desde el 11 de septiembre de 2026 el Cyber Resilience Act obliga a notificar en 24 horas las vulnerabilidades explotadas activamente, y desde el 11 de diciembre de 2027 ninguna app podrá comercializarse en la UE sin cumplir sus requisitos esenciales. El techo sancionador: 15 millones de euros o el 2,5% de la facturación mundial, según la estructura de sanciones del reglamento.

En Docastix construimos apps móviles nativas y multiplataforma desde Galicia, y esto es lo que le contamos a un cliente cuando pregunta «¿y esto es seguro?». No es una lista de buenas prácticas: es qué te obliga la ley, qué te tumba una review de tienda, qué se arregla gratis en desarrollo y qué solo se resuelve pagando.

Respuesta rápida: qué necesita tu app para ser segura y publicable

La seguridad de una app se juega en cinco capas y solo una es cara. Cuatro se resuelven durante el desarrollo si las pides antes de escribir código; la quinta, la verificación externa, cuesta dinero. El error caro no es saltarse el pentest: es llegar a él con una arquitectura que hay que rehacer.

Tres cifras para quedarte: un pentest de app móvil arranca en 5.000 €, el CRA empieza a morder el 11 de septiembre de 2026 y la AEPD recibió 2.765 notificaciones de brecha en 2025, el 80% del sector privado.

El OWASP Mobile Top 10, traducido a lenguaje de negocio

El OWASP Mobile Top 10 se actualizó en 2024 y el cambio importa: la lista antigua encabezaba con «uso indebido de la plataforma»; la nueva pone primero el uso incorrecto de credenciales y segundo la cadena de suministro. Hoy te entran por donde confías, no por donde programas.

M2 se ha vuelto crítico porque una app arrastra decenas de dependencias: el informe de Verizon de 2025 sitúa la implicación de terceros en el 30% de las brechas, el doble que el año anterior. El manual completo es el MASVS de OWASP: ese es el documento que debería estar sobre la mesa cuando pides presupuesto de seguridad, no una lista de herramientas.

Qué te obliga el RGPD y qué mira de verdad la AEPD

El RGPD no te pide «ser seguro». Te pide demostrar que aplicaste medidas apropiadas al riesgo (artículo 32), que recoges el mínimo necesario, que tienes base legal para cada tratamiento y que borras cuando te lo piden.

Sobre las multas conviene ser preciso. El artículo 83 tiene dos tramos: los fallos de seguridad y las obligaciones del responsable (artículos 25 a 39, donde vive el 32) van al de 10 millones de euros o el 2% del volumen de negocio anual mundial; incumplir principios, consentimiento o derechos (artículos 5, 6, 7, 9 y 12 a 22) sube a 20 millones o el 4%. Filtrar datos es caro; recogerlos sin base legal, más.

Los datos de la AEPD de 2025 dibujan el terreno real: 2.765 notificaciones de brecha, el 80% privadas, y más de 200 millones de comunicaciones a afectados. Los vectores más dañinos fueron el ransomware y las credenciales comprometidas usadas para entrar en VPN y CRM; la Agencia señala el segundo factor de autenticación como la medida más eficaz. Y solo 11 derivaron en investigación adicional: notificar a tiempo cuenta como diligencia.

Lo aplicable a tu app: base legal por tratamiento (analítica, publicidad y funcionamiento no se cubren con un único «acepto»); consentimiento antes de inicializar el SDK, no en la pantalla siguiente; contrato de encargado con cada proveedor que toque datos; 72 horas para notificar la brecha; y borrado real, porque desactivar no es borrar. Este frente convive con otro que muchas pymes ignoran: la normativa europea de accesibilidad, vigente desde junio de 2025 y con sanciones propias. Se auditan igual: lo que no está documentado, no existe.

Cyber Resilience Act: las fechas que sí te afectan

El Cyber Resilience Act (Reglamento UE 2024/2847) impone requisitos de ciberseguridad obligatorios a los productos con elementos digitales durante todo su ciclo de vida, y el software descargable, apps móviles incluidas, entra en su ámbito según la guía de la Comisión analizada por Cuatrecasas.

El calendario, según la página oficial de la Comisión y el resumen de INCIBE:

Lo que tienes que montar: seguridad por diseño y por defecto, sin vulnerabilidades explotables conocidas al publicar; un periodo de soporte declarado públicamente, normalmente de al menos cinco años, con actualizaciones gratuitas; un SBOM legible por máquina con tus dependencias, lo que convierte M2 de OWASP en obligación legal; una política de divulgación de vulnerabilidades; notificación en 24 horas de una vulnerabilidad explotada activamente e informe completo en 72, según el análisis de DLA Piper; y marcado CE.

Una precisión que ahorra sustos: el SaaS puro accesible solo por navegador queda fuera, pero tu backend suele entrar. La lectura del ámbito sobre tratamiento remoto de datos es que un backend está dentro si es necesario para una función esencial, lo has desarrollado tú y hay flujo de datos en ambos sentidos. Si tu app no funciona sin tu API, tu API es producto regulado; si construyes una plataforma SaaS con app encima, asume que el conjunto entra. Y además de la multa, la autoridad puede exigir la retirada del producto.

Qué exigen App Store y Google Play antes de dejarte publicar

Las tiendas ejercen de reguladores de facto y no negocian. Aquí es donde vemos caer más reviews.

• Privacy manifests (Apple). Desde el 1 de mayo de 2024, según el aviso de Apple, toda app nueva o actualizada que incorpore un SDK de su lista de uso común debe subir los motivos declarados de cada API sujeta a justificación, los privacy manifests y firmas válidas del SDK. Esa lista incluye Firebase, los SDK de Google, los de Meta y Flutter. Falta un motivo, rechazo.
• Borrado de cuenta. Desde el 30 de junio de 2022, la guía 5.1.1(v) exige que toda app con registro permita borrar la cuenta desde dentro, con borrado real de los datos. Google Play pide además una URL web pública; su prórroga acabó el 31 de mayo de 2024.
• Seguridad de los datos (Google Play). El formulario obliga a declarar qué datos recoges, con quién los compartes, si hay cifrado en tránsito y cómo se borran. La exactitud es responsabilidad solo tuya y la discrepancia se castiga con bloqueo de actualizaciones o retirada.
• Estatus de comerciante (DSA). Apple exige declarar el estatus de comerciante de los artículos 30 y 31 del DSA, con contacto verificado y documentación de empresa. Sin eso no envías app nueva a la UE.
• Verificación de desarrollador (Android). Google extiende la verificación de identidad a apps distribuidas fuera de Play: efectiva en cuatro países en septiembre de 2026 y global en 2027.

Nada de esto cuesta dinero más allá de las cuentas de desarrollador —99 €/año en Apple, 25 € de pago único en Google—, pero cuesta calendario si te enteras tarde.

Cuánto cuesta la seguridad en aplicaciones móviles

El criterio que casi ningún artículo menciona: qué se arregla barato y qué solo se arregla pagando.

Dentro del desarrollo, sin partida específica:

• Tokens y datos sensibles en Keychain (iOS) y Keystore (Android), nunca en UserDefaults ni SharedPreferences.
• TLS bien configurado y, si el riesgo lo justifica, certificate pinning. Nunca dejar activa la excepción de certificados de desarrollo.
• Cero secretos en el binario: las claves de terceros viven en el backend.
• Autorización siempre en servidor. El cliente pide, el servidor decide. Es el fallo más común y el más barato de prevenir.
• Tokens de vida corta con refresco y biometría para operaciones sensibles.
• Logs de depuración desactivados en release y datos sensibles fuera de los backups.
• Escaneo de dependencias y análisis estático en CI. Las herramientas base son gratuitas y cubren buena parte de M2.

Son horas de un perfil senior —65-110 €/h en España—. Pedirlo al principio es casi gratis; pedirlo con 40 pantallas construidas es rehacer arquitectura.

Requiere gasto externo:

• Pentest de app móvil: desde 5.000 €, con análisis estático y dinámico, API, almacenamiento local y comunicaciones, según los rangos de CISEC para España. El de web parte de 3.500 € y el de infraestructura de 4.000 €.
• Auditoría de alcance completo: 15.000-40.000 € o más, de tres a seis semanas, según rangos de mercado de 2026. Una auditoría web sola va de 3.000 a 12.000 €, y una fintech a la parte alta.
• Escaneo automatizado continuo: 50-500 €/mes según activos. Cubre el hueco entre auditorías, pero no valida la lógica de negocio.

La forma sana de presupuestarlo es meterlo en el coste total de propiedad. Como explicamos en la guía de cuánto cuesta hacer una app, el mantenimiento ronda el 15-20% del coste de desarrollo al año y la gestión de vulnerabilidades del CRA vive ahí. En Docastix el evolutivo arranca en 500 €/mes.

Un apunte sobre pagos, donde más dinero se pierde por errores evitables: nunca valides una compra o suscripción solo en el dispositivo. La validación de recibos ocurre en tu servidor contra las APIs de Apple y Google. Lo detallamos al hablar de monetización de apps: validar en local es regalar tu producto. En Dormus, nuestra app de sueño infantil con más de 50.000 descargas y 22.500 usuarios activos, el cliente pregunta y el servidor decide.

¿Y lo de siempre, nativo o multiplataforma? Casi no decide: los hallazgos de un pentest están en arquitectura y backend, no en el lenguaje. Lo que cambia es la superficie de dependencias y la rapidez para parchear, y eso sí pesa al elegir entre nativo y multiplataforma.

Checklist antes de publicar

Si tu equipo no responde que sí a todo, todavía no estás listo.

Datos y dispositivo

• Tokens y credenciales en Keychain/Keystore, nunca en claro.
• Ningún secreto de terceros en el binario, verificado descompilando la release.
• Logs de depuración fuera y datos sensibles excluidos de backups.

Red y backend

• TLS obligatorio en todos los endpoints, sin excepciones de certificado.
• Autorización en servidor, con pruebas de acceso cruzado entre usuarios.
• Rate limiting y validación de entrada en la API.
• Validación de compras y suscripciones en servidor.

Privacidad y legal

• Inventario de datos personales con base legal y plazo de conservación.
• Consentimiento antes de inicializar SDK de analítica o publicidad.
• Contratos de encargado firmados y procedimiento escrito de notificación en 72 horas.

Tiendas

• Formulario de Seguridad de los datos revisado contra los SDK de la build actual.
• Privacy manifest y firmas de SDK en orden para App Store Connect.
• Borrado de cuenta en la app y URL web pública de solicitud.
• Estatus de comerciante del DSA declarado y verificado.

Ciclo de vida (CRA)

• SBOM generado automáticamente en cada build y periodo de soporte publicado.
• Canal de divulgación de vulnerabilidades con responsable asignado.
• Escaneo de dependencias en CI que rompe la build ante vulnerabilidades críticas.

Conclusión

Tienes tres relojes corriendo a la vez: el RGPD, con sus dos tramos de sanción; las tiendas, que rechazan sin apelación; y el CRA, con notificación obligatoria desde septiembre de 2026 y aplicación plena en diciembre de 2027. Ninguno se arregla con una auditoría de última hora.

Lo que funciona es lo aburrido: decidir la arquitectura de datos antes de la primera pantalla, no meter secretos en el binario, comprobar permisos en servidor, mantener vivo el inventario de dependencias y reservar presupuesto anual para que alguien de fuera intente romperlo. Si arrancas un proyecto y quieres esto incorporado en vez de parcheado, escríbenos desde contacto o pasa por nuestro presupuestador. Y si ya tienes app en producción, el orden es checklist primero y pentest después.