Los neobancos independientes quedan atrás en seguridad de aplicaciones: 79% frente al 51%

Los neobancos obtienen peores resultados que los bancos tradicionales en seguridad de aplicaciones móviles en nuestro estudio de 2026. En los neobancos independientes, la diferencia es considerable: el 79.3% de sus aplicaciones presenta al menos un hallazgo de severidad alta o crítica, frente al 51.2% de las aplicaciones de bancos tradicionales. Una brecha de 28.1 puntos porcentuales.

Los bancos construidos en torno a una aplicación deberían tener todos los motivos para cuidarla. Sin embargo, los neobancos independientes distribuyen aplicaciones con credenciales integradas con más del doble de frecuencia que los bancos tradicionales, incluso mientras los superan en passkeys y atestación de la aplicación. Las funciones de seguridad modernas conviven con debilidades básicas.

Estos son los resultados del Informe 2026 de seguridad de aplicaciones de banca móvil de Ostorlab, que abarca 2,686 aplicaciones de 487 bancos de 64 países. La diferencia más marcada separa a los neobancos independientes del resto.

La brecha es de 28 puntos. La propiedad importa.

Agrupar todos los neobancos oculta lo esencial. Entre ambos tipos, el 61.1% de sus aplicaciones presenta un hallazgo de severidad alta o crítica. Al separarlos según quién los posee, surgen dos situaciones muy distintas:

Los neobancos propiedad de un banco se parecen mucho a sus entidades matrices. Los neobancos independientes explican la brecha.

El grupo independiente es pequeño: 29 aplicaciones de 10 bancos, con aproximadamente un tercio de las aplicaciones pertenecientes a un solo banco. El informe observa que la brecha persiste cuando se asigna el mismo peso a cada banco y cuando se tiene en cuenta la distribución de plataformas, pero su magnitud sigue siendo orientativa. La diferencia se concentra en los hallazgos de severidad alta; los hallazgos críticos aparecen con frecuencias similares en los tres grupos. Son hallazgos del escáner en aplicaciones distribuidas, no una medición de la frecuencia de brechas de seguridad.

Más passkeys. Más secretos expuestos.

Los neobancos independientes van por delante en algunos de los controles que los equipos de seguridad quieren que adopten los bancos. El 37.9% integra una API de passkeys, frente al 4.6% de las aplicaciones de bancos tradicionales. El 48.3% utiliza atestación de la aplicación o del dispositivo, frente al 19.9%.

Sin embargo, el 48.3% incluye credenciales distintas de las claves de API de Google, frente al 19.8% de las aplicaciones de bancos tradicionales. Los hallazgos de severidad alta o crítica relacionados con la toma de control de cuentas mediante OAuth aparecen en el 24.1%, frente al 6.1%: casi cuatro veces más a menudo.

Una passkey puede proteger el inicio de sesión frente al phishing. No puede eliminar una clave privada incluida en la aplicación ni corregir otro flujo de OAuth. Añadir un control sólido no compensa una debilidad en otro punto. Para el equipo de seguridad de un banco, la pregunta útil es si todo el recorrido, desde el inicio de sesión hasta el pago, resiste.

Los bancos tradicionales tienen poco que celebrar

El grupo con mejores resultados sigue presentando hallazgos graves en aproximadamente la mitad de sus aplicaciones. En el conjunto de la muestra, el 51.5% presenta un hallazgo de severidad alta o crítica, el 20.3% incluye una credencial que debería ser secreta y el 41.1% distribuye un componente de terceros con una vulnerabilidad publicada.

Las credenciales incluyen claves privadas, claves de servicios en la nube y tokens de servicio. Una aplicación se distribuye a los dispositivos de los clientes; cualquier elemento incluido en ella se puede extraer. Un secreto necesario para proteger los servicios del banco no debería depender de permanecer oculto ahí.

Las claves de API de Google se contabilizan por separado. Muchas están diseñadas para distribuirse con Maps o Firebase, por lo que encontrar una no demuestra que exista una fuga. Su riesgo depende de las restricciones, que este estudio no comprobó. No se probó ninguna de las credenciales encontradas.

La propia aplicación del banco puede convertirse en la herramienta del atacante

Las campañas recientes muestran por qué importa la integridad de la aplicación. GoldFactory modifica aplicaciones bancarias legítimas. Gigabud las clona en un perfil de trabajo oculto. Hirudo sustituye la aplicación real por una copia modificada. La interfaz de confianza puede mantenerse mientras el código que hay debajo sirve al atacante.

Sin embargo, el 79.8% de las aplicaciones no muestra atestación de la aplicación ni del dispositivo, y solo el 22.3% de las aplicaciones Android detecta las herramientas de control remoto utilizadas para cometer fraude desde el dispositivo de la víctima. La atestación de la aplicación puede ayudar a identificar una copia manipulada, pero solo ayuda al banco si el servidor actúa en función del resultado. La aplicación por sí sola no permite verificar si el servidor hace cumplir ese control.

La biometría requiere el mismo escrutinio. El escáner señaló flujos de inicio de sesión biométrico que se podían eludir en el 35.1% de las aplicaciones Android. La solidez de una solicitud de huella digital depende de la operación que protege: un flujo que solo comprueba un resultado de sí o no se puede omitir. Las acciones sensibles deben exigir la clave criptográfica desbloqueada mediante la comprobación biométrica.

El impacto económico ya es visible. La banca móvil concentró £301.8 millones, el 52%, de las pérdidas por estafas de pago autorizado en el Reino Unido en 2025, según UK Finance. Estas pérdidas son una evidencia independiente de lo que está en juego, no pérdidas atribuidas a los hallazgos de este estudio.

Qué debe cambiar antes de la próxima versión

Para los responsables de los bancos, la comparación exige evidencias de que las protecciones funcionan en conjunto. Para los equipos de ingeniería y seguridad, el punto de partida son estas comprobaciones, extraídas de las recomendaciones del informe y vinculadas en él a OWASP MASVS:

1. Retirar los secretos de la aplicación distribuida. Mantener las claves privadas y las credenciales de servicio en el servidor. Proporcionar a la aplicación tokens de corta duración y acceso limitado.
2. Corregir las vulnerabilidades conocidas de las dependencias. Mantener una lista de materiales de software para cada versión y fijar un plazo para corregir los componentes críticos.
3. Probar el recorrido desde el inicio de sesión hasta el pago. Vincular las acciones sensibles a claves respaldadas por hardware, comprobar los flujos de OAuth y ofrecer passkeys. Probar si un control se puede eludir, no solo si su API aparece en el código.
4. Hacer que la integridad de la aplicación sea una decisión del servidor. Validar los veredictos de Play Integrity o App Attest en el servidor y actuar ante los fallos. Probar las defensas en tiempo de ejecución frente a las herramientas actuales de los atacantes en dispositivos reales.
5. Tener en cuenta el riesgo del dispositivo en el momento decisivo. Comprobar el nivel de parches al iniciar sesión y restringir las acciones de alto riesgo en dispositivos sin parches. Detectar las herramientas de control remoto antes de que conviertan una sesión legítima en fraude.

La pregunta para la revisión de la próxima versión es concreta: ¿puede el equipo demostrar que un atacante no puede saltarse las comprobaciones que protegen una cuenta o un pago?

Lea el informe completo para consultar la comparación por tipo de banco, las tablas por país, cuatro casos de estudio de ataques y las ocho acciones recomendadas. Ponga a prueba estos controles en su propia aplicación con Ostorlab para banca.

Qué midió el estudio

Entre el 28 de octubre y el 5 de noviembre de 2026, recopilamos 2,841 fichas de aplicaciones bancarias y analizamos 2,686 aplicaciones en Android, iOS y HarmonyOS. La muestra abarca 487 bancos, incluidos 29 bancos de importancia sistémica mundial, y es cinco veces mayor que la de nuestra edición de 2025. La muestra y el método cambiaron, por lo que las ediciones no representan una tendencia interanual.

Cada aplicación pasó por un análisis estático, un escaneo rápido automatizado y dieciséis comprobaciones de controles de autenticación y pago, junto con una revisión de los datos públicos del banco. Un hallazgo es una coincidencia con una regla del escáner en el paquete distribuido, no una prueba de que se pueda explotar. No se atacó ninguna aplicación, no se probó ningún inicio de sesión y no se utilizó ninguna credencial descubierta. Las protecciones del servidor pueden ser invisibles para este método. Las comprobaciones que requieren código legible excluyen las aplicaciones con código empaquetado: los resultados generales de passkeys se calculan sobre 2,586 aplicaciones y los de atestación sobre 2,602. Los resultados son agregados; no se nombra a ningún banco ni a ninguna aplicación.