La seguridad de las aplicaciones móviles se prepara antes del lanzamiento, no después del primer incidente. Para reducir los riesgos, hay que comprobar el almacenamiento de datos, las comunicaciones de red, la autenticación, los permisos, las dependencias de software, el cumplimiento del RGPD y los requisitos de la App Store y Google Play. Por lo general, hay que contar con entre 2 y 5 días de auditoría para una aplicación sencilla, y más si gestiona pagos, datos sanitarios, geolocalización o datos sensibles.
Seguridad de la aplicación móvil: lo que hay que controlar antes de la publicación
Una aplicación móvil no es solo una interfaz colocada sobre un teléfono. A veces almacena información, se comunica con una API (servidor que proporciona los datos), utiliza sensores, solicita permisos y depende de bibliotecas de terceros. Cada elemento puede crear una vulnerabilidad.
El marco de referencia más útil para delimitar el tema sigue siendo el OWASP MASVS, mantenido por OWASP, una fundación reconocida en seguridad de aplicaciones. En 2025, su checklist MAS cubre en particular el almacenamiento, la criptografía, la autenticación, la red, la plataforma, el código, la resiliencia y la privacidad. No está reservado a los bancos. Es una base sólida para cualquier aplicación seria.
El NIST, organismo estadounidense de normalización, también normalizó ya en 2019 un proceso de verificación de aplicaciones móviles en la publicación SP 800-163 Rev. 1. La idea es sencilla: una aplicación debe evaluarse en función de unos requisitos de seguridad definidos, mediante análisis estáticos, dinámicos y computacionales. En otras palabras: leer el código, probar la aplicación en funcionamiento y observar lo que realmente hace.
La checklist antes de la puesta en línea
Aquí tiene la lista corta que cualquier directivo puede pedir a su proveedor antes de validar una publicación. No sustituye una prueba de intrusión, pero evita los olvidos graves, los que salen caros una vez que la aplicación está en manos de los usuarios.
- Verificar que los datos sensibles no se almacenan en claro en el teléfono.
- Forzar HTTPS para los intercambios con el servidor, cuando el protocolo sea comportible.
- Limitar los permisos de Android e iOS a lo estrictamente necesario.
- Controlar las dependencias open source y eliminar las que tengan vulnerabilidades conocidas.
- Probar la autenticación, el cierre de sesión, la expiración de la sesión y la recuperación de contraseña.
- Validar las entradas del usuario para evitar inyecciones, abusos y fallos.
- Preparar una política de privacidad clara, accesible en la app y en los metadatos de las stores.
- Poner en marcha un procedimiento de actualización rápida en caso de vulnerabilidad.
En los proyectos que llevamos a cabo, vemos a menudo una diferencia entre el esforzo puesto en la interfaz y el dedicado a los escenarios de abuso. Sin embargo, el riesgo no siempre proviene de un pirata sofisticado. A veces proviene de un token de acceso (clave temporaria de conexión) conservado demasiado tiempo, de un archivo de logs demasiado verboso o de un permiso de cámara solicitado “por si acaso”.
Datos, permisos y RGPD: el tríptico que pesa sobre el riesgo
El primer ahorro consiste en no recopilar lo que no necesita. Menos datos es menos responsabilidad, menos costes de securización y menos fricción lors de la validación por las stores. El RGPD, aplicable desde 2018, obliga a justificar la recopilación, a informar al usuario y a proteger los datos personales.
Android recomienda en 2026 minimizar los permisos, utilizar el almacenamiento interno cuando sea posible y validar las entradas. El almacenamiento interno significa que los archivos están aislados en el espacio privado de la aplicación, en lugar de quedar expuestos a otras apps o al usuario mediante una carpeta compartida. Esta elección técnica tiene un efecto directo sobre su nivel de riesgo.
Apple exige también, en sus App Store Review Guidelines actualizadas en junio de 2026, un enlace a la política de privacidad en App Store Connect y dentro de la aplicación. Es un punto sencillo de prever, pero un descuido puede bloquear la publicación. Perder una semana por una página de privacidad que falta resulta frustrante.
La trampa clásica: pedir demasiados permisos al iniciarse. Una app de cita previa que solicita contactos, geolocalización y notificaciones antes de haber explicado su uso despierta desconfianza. A igual presupuesto, es mejor un recorrido más sobrio que un proceso lleno de funcionalidades pero que genere ansiedad.
Código, dependencias y plateformes: lo que las stores también miran
La seguridad de una aplicación móvil también depende de la actualización técnica. Google Play impone en 2025 que las nuevas aplicaciones Android y las actualizaciones apunten a Android 15, API level 35 o superior, con reglas específicas para Wear OS, Android Automotive OS y Android TV. Este nivel objetivo indica a Android qué protecciones modernas acepta utilizar la aplicación.
Google Play también exige Play App Signing para las apps distribuidas a través de Google Play, salvo las aplicaciones antiguas creadas antes de agosto de 2021 que pueden encore distribuir APK auto-firmados. La firma sirve para demostrar que una actualización procede del editor correcto. Si esta cadena se gestiona mal, puede acabar bloqueado en el momento de corriger una vulnerabilidad.
El OWASP MASVS-CODE recomienda en 2025 tres reflejos previos a la publicación: utilizar una versión de plateforme actualizada, imponer las actualizaciones de la aplicación cuando sea necesario y utilizar únicamente componentes sin vulnerabilidades conocidas. Dicho de otro modo: una app bonita construida sobre una dependencia abandonada sigue siendo frágil.
En el caso de las arquitecturas híbridas o de JavaScript, también hay que prestar atención al entorno de ejecución, los paquetes npm y los puentes nativos. Por lo tanto, la elección técnica inicial tiene repercusiones en materia de seguridad, mantenimiento y plazos; nuestra comparativa sobre los runtimes JavaScript modernos ayuda a comprender estos arbitrajes del lado del servidor o de las herramientas.
Presupuesto y plazos realistas para asegurar una aplicación
La cuestión presupuestaria llega rápido. Es legítima. En Francia, según los proveedores, una revisión de seguridad ligera antes de la publicación suele empezar en torno a 1 500 a 3 000 € sin IVA para una aplicación sencilla, sin datos muy sensibles. Una auditoría más completa con análisis de código, pruebas dinámicas y rapport utilizable se sitúa más bien entre 4 000 y 12 000 € sin IVA.
Para una aplicación fintech, sanitaria, marketplace o con área de cliente que exponga documentos, el presupuesto puede aumentar. No por lujo. Porque hay que probar más escenarios: suplantación de cuenta, acceso a datos de otro usuario, interceptación de red, compromiso del teléfono, elusión del pago.
| Control antes de la publicación | Plazo habitual | Presupuesto orientativo Francia | Cuándo preverlo |
|---|---|---|---|
| Checklist OWASP MAS básica | 1 a 2 días | 800 a 2 000 € sin IVA | Aplicación escaparate o MVP sin datos sensibles |
| Auditoría de seguridad móvil estándar | 3 a 5 días | 3 000 a 7 000 € sin IVA | Espacio cliente, API, autenticación, datos personales |
| Prueba de intrusión móvil exhaustiva | 1 a 3 semanas | 8 000 a 20 000 € sin IVA | Pago, salud, finanzas, datos confidenciales |
| Remediación tras auditoría | 2 días a 3 semanas | Según corrections | Antes de la presentación en App Store y Google Play |
Sinceramente, no siempre está justificado hacer una prueba de intrusión completa sobre un prototipo desechable. En cambio, publicar una app para clientes sin una revisión mínima del almacenamiento, los permisos y la API es un falso ahorro. El enfoque adecuado consiste en adaptar el nivel de control a la exposición real.
Los errores que hacen fracasar una publicación o disparan el mantenimiento
Apple exige aplicaciones finales y probadas lors de la presentación. Sus normas de 2026 también indican que las apps se analizan para detectar malware, software perjudicial para la seguridad, la protección y la privacidad. Por tanto, una app inestable o incompleta puede ser rechazada sin ni siquiera hablar de ciberseguridad avanzada.
En Android, el problema suele venir de una acumulación de compromisos: permisos demasiado amplios, dependencias sin mantenimiento, configuración de red permisiva, ausencia de estrategia de actualización. Individualmente, cada punto parece menor. En conjunto, crean una deuda de seguridad.
Un caso frecuente: el equipo reporte la seguridad “después de la V1”. Mal cálculo si la arquitectura de autenticación es débil, porque la corriger a posteriori afecta a la aplicación, la API, las cuentas de usuario y, a veces, al support cliente. En esta fase, el coste ya no es el de un control; es el de una rehacer.
La normativa renforce también la presión sobre ciertos sectores. Las pymes afectadas por obligaciones ciber pueden consultar nuestras referencias sobre el Cyber Resilience Act, DORA para los servicios financieros o la directiva NIS2. Aunque su aplicación no entre directamente en estos marcos, sus clientes de grandes cuentas pueden pedirle pruebas de seguridad.
Cómo gestionar el tema sin convertirse en experto técnico
No necesita leer todo el código para gestionar correctamente la seguridad de la aplicación móvil. Pida más bien entregables verificables: una checklist cumplimentada, la lista de dependencias, las versiones objetivo de Android y iOS, los permisos justificados, un informe de auditoría con gravedad y correcciones priorizadas. Algo concreto.
Por parte de la agencia, el reflejo es tratar la seguridad como un criterio de validación, al mismo nivel que la performancia o la ergonomía. Eso cambia los plazos: se reservan algunos días antes de la publicación, en lugar de descubrir los fallos durante el envío o tras un comentario inquietante de un usuario.
La seguridad del servidor cuenta tanto como la propia aplicación. Una app móvil irreprochable que consulta una API mal protegida sigue siendo vulnerable. Los temas de certificados, cifrado y refuerzo de la infraestructura se suman además a las cuestiones abordadas en nuestro análisis sobre la evolución de los certificados SSL.
Definir este tipo de proyecto de antemano evita la mayoría de las malas sorpresas: rechazo de la tienda, sobrecoste presupuestario, corrección tardía o pérdida de confianza. Una mirada externa ayuda sobre todo a elegir el nivel adecuado de esforerzo, ni simbólico ni desproporcionado.
Preguntas frecuentes sobre la seguridad de una aplicación móvil
¿Cuándo hay que hacer una auditoría de seguridad móvil?
Idealmente antes de la publicación, cuando las funcionalidades son estables pero aún queda tiempo para corregir. Para una app sensible, prevea la auditoría al menos 2 a 4 semanas antes de la fecha de lanzamiento.
¿Es segura una aplicación validada por Apple o Google?
No exactamente. Las stores filtran ciertos riesgos, imponen reglas y pueden analizar las apps, pero su validación no sustituye una auditoría de su código, de su API y de sus decisiones de almacenamiento.
¿Cuál es la prioridad si el presupuesto de seguridad es limitado?
Empiece por la autenticación, los datos almacenados en el teléfono, los permisos y las comunicaciones HTTPS con la API. A menudo son las áreas en las que un error simple crea un riesgo elevado.
¿La seguridad retrasa necesariamente la salida de la aplicación?
Retrasa sobre todo los proyectos en los que llega demasiado tarde. Integrada desde las pruebas de aceptación, una lista de comprobación seria añade algunos días, pero evita correcciones más largas después del rechazo del store o de un incidente.