Seguridad Mobile | Pentest | Fintech

Seguridad Mobile en Fintech: lo que un pentest encuentra en la app que su escáner nunca ve

09 ago 2026· 12 min de lectura· Nivel: Intermedio

Categoría: Seguridad Mobile | Pentest | Fintech Nivel: Intermedio Entorno: Laboratorio controlado — escenario totalmente anonimizado, sin datos reales de clientes

Introducción

Su app de banco está en la Play Store con 4,8 estrellas. El equipo de ingeniería hace code review, el pipeline ejecuta SAST en cada push y el backend pasó por un escaneo automatizado en la última release. Aun así, cuando empieza un pentest mobile, lo primero que encuentra el testador suele sorprender: los problemas más graves no están en el backend — están en la app que usted publicó.

Las fintechs procesan el tipo de activo que más persiguen los adversarios: dinero, datos bancarios, tokens de sesión y PII en volumen. El smartphone se convirtió en la interfaz principal de ese flujo, y la seguridad mobile tiene una característica única: el código de la app está en el bolsillo del atacante. A diferencia del backend, que usted protege detrás de firewall y WAF, el APK/IPA se distribuye a millones de dispositivos — cualquiera puede descargarlo, descompilarlo y estudiar su app como quien lee un libro abierto.

Este material es preventivo y describe, en un escenario de laboratorio anonimizado, lo que un pentest mobile encontró en una fintech ficticia ("PayFlow") — y por qué cada hallazgo representa un riesgo real para cualquier empresa que mueva dinero por app.

1. Por qué la seguridad mobile es diferente (la física del problema)

Antes de los hallazgos, vale entender por qué la app exige un enfoque propio:

El atacante tiene el binario. El backend es caja negra; la app es caja blanca. Con jadx, apktool o MobSF, cualquier persona convierte un APK en código legible en minutos. Un secreto que vive en la app no es un secreto — es una cuenta regresiva.
El dispositivo es hostil. La app corre en un entorno que el usuario controla: con root, con hooking (Frida), con un proxy que intercepta el tráfico. Si la app confía en el dispositivo, el atacante controla la app.
La API mobile es una superficie paralela. Muchas fintechs mantienen endpoints específicos de la app con controles más débiles que los de la web — y versiones antiguas de la API siguen en el aire años después.
El daño es directo. La fuga de un token de sesión, el bypass de autenticación o una clave de API expuesta en una fintech significan acceso al saldo, a transferencias y a datos bancarios — no solo "exposición de infraestructura".

El OWASP Mobile Top 10 (2024) organiza bien lo que más se repite en pruebas reales: uso inadecuado de credenciales (M1), comunicación insegura (M5), autenticación/autorización inseguras (M3), almacenamiento inseguro de datos (M9) y protecciones binarias insuficientes (M7) — exactamente los patrones que reproducen los hallazgos siguientes.

2. El escenario de laboratorio: la fintech "PayFlow"

Para mostrar el flujo completo, usamos un escenario ficticio de laboratorio: PayFlow, fintech de pagos con 2 millones de usuarios activos, apps Android e iOS, que mueve Pix, tarjetas y cuentas digitales. Contrató un pentest mobile con la siguiente orientación: probar la app como lo haría un adversario real — descargar el APK, descompilar, analizar estáticamente y luego atacar la API detrás de la app con un proxy.

El resultado: ocho hallazgos, todos con reproducción, todos clasificados por el impacto real para el negocio. A continuación, los cinco más representativos.

3. Los hallazgos (escenario anonimizado)

Hallazgo 1 — [CRÍTICO] Clave de API y secreto de firma hardcoded en el APK

En el análisis estático del APK (jadx + apkleaks), el testador encontró una API key de un servicio de pagos de terceros y el secreto usado para firmar tokens JWT incrustados en el código, en una clase de configuración.

Reproducción: extracción del APK de la Play Store → descompilación → strings/constantes en texto plano.
Por qué ocurre: el equipo necesitaba una forma simple de autenticar la app contra el servicio y "escondió" el secreto en el código del cliente, creyendo que la ofuscación bastaba.
Impacto: con el secreto de firma, un atacante forja tokens JWT y se hace pasar por cualquier usuario — incluidos los usuarios administrativos, si el backend no diferencia el token de la app del token de admin. La clave de terceros permite gastar crédito del servicio de pagos en nombre de PayFlow.
Lección: un secreto que debe vivir en el backend no puede vivir en la app. Cualquier credencial embebida es, por definición, pública.
OWASP Mobile Top 10 (2024): M1 (Improper Credential Usage) + M7 (Insufficient Binary Protections) — la ofuscación no es control de acceso.

Hallazgo 2 — [ALTO] Sin certificate pinning: tráfico interceptable vía proxy

La app solo validaba la cadena de certificados del sistema operativo — sin certificate pinning. El testador logró interceptar el tráfico por dos caminos: la instalación de la CA de Burp Suite en el dispositivo funcionó porque la app confiaba en CAs de usuario (común en builds de desarrollo o con networkSecurityConfig permisivo); en apps Android modernas (targetSdk ≥ 24), que no confían en CAs de usuario por defecto, el camino real es el bypass vía Frida.

Reproducción: proxy en la red → instalación de CA (builds de desarrollo/networkSecurityConfig permisivo) o bypass vía Frida → tráfico de la app decodificado en Burp.
Por qué ocurre: el pinning dificulta el desarrollo (certificados de staging, pruebas en CI) y el equipo postergó la implementación.
Impacto: en un escenario real, el mismo tráfico interceptado contiene tokens de sesión y payloads con datos bancarios. El pinning no es una defensa absoluta (un atacante con acceso al dispositivo usa Frida para sortearlo), pero eleva el costo del ataque e impide la interceptación pasiva en redes públicas — la puerta de entrada más común.
Lección: el pinning es higiene básica para una app que mueve dinero; sin él, la app depende enteramente del TLS del SO.
OWASP Mobile Top 10 (2024): M5 (Insecure Communication).

Hallazgo 3 — [ALTO] Tokens de sesión y datos bancarios almacenados en texto plano en el dispositivo

El análisis dinámico (dispositivo con acceso root + Frida) reveló que la app guardaba el token de sesión y el último extracto consultado en SharedPreferences y en archivos SQLite en texto plano — sin cifrado, sin Keychain/Keystore.

Reproducción: navegar en la app → inspeccionar /data/data/<paquete>/shared_prefs y el SQLite local.
Por qué ocurre: almacenar el token en memoria persistente fue la solución rápida para mantener al usuario con sesión iniciada sin reautenticar en cada apertura.
Impacto: un dispositivo comprometido (malware/root), o un equipo perdido/robado sin bloqueo de pantalla/FBE o con allowBackup=true (extracción vía adb backup), entrega el token de sesión — y, con él, acceso a la cuenta sin necesidad de contraseña. Los datos bancarios almacenados localmente amplían el daño de un simple robo de celular.
Lección: los tokens deben vivir en el almacenamiento seguro del SO (Keystore/Keychain), con corta duración; los datos sensibles no deben persistirse en el dispositivo sin necesidad — y, si se persisten, cifrados con una clave derivada del Keystore.
OWASP Mobile Top 10 (2024): M9 (Insecure Data Storage).

Hallazgo 4 — [ALTO] Endpoints de API mobile con controles más débiles que los de la web

La app conversaba con una API dedicada (api-mobile.payflow.app) que no exigía los mismos controles que la API web: rate limiting ausente, sin validación de versión de la app y respuestas con más datos de los que la pantalla necesita (ej.: el endpoint de saldo devolvía también el historial completo de transacciones y el CPF completo del usuario).

Reproducción: el análisis estático reveló el endpoint; el proxy mostró el payload completo de la respuesta.
Por qué ocurre: la API mobile se creó después, por otro equipo, con prisa por lanzar — y nadie revisó si los controles de la API web aplicaban a ella.
Impacto: la ausencia de rate limiting abre el camino a enumeración de cuentas y ataques de fuerza bruta; el exceso de datos en la respuesta convierte un endpoint legítimo en fuente de exfiltración para un atacante con token filtrado (o en un escenario de acceso indebido).
Lección: la API mobile no es una API diferente — es la misma superficie de riesgo, con el agravante de descubrirse con facilidad desde la propia app.
OWASP Mobile Top 10 (2024): M3 (Insecure Authentication/Authorization) — el rate limiting ausente y el exceso de datos en la respuesta agravan el M3.

Hallazgo 5 — [MEDIO] Deep links manipulables (apertura de pantallas sensibles sin validación de origen)

La app registraba deep links (payflow://transferencia?valor=...) y los abría sin validar el origen del intent/URL scheme. En un escenario de ataque, un enlace malicioso disparado por SMS o un sitio comprometido podía abrir pantallas de transferencia pre-rellenadas dentro de la app autenticada.

Reproducción: adb shell am start -a android.intent.action.VIEW -d "payflow://transferencia?valor=9999" en un dispositivo con la app con sesión iniciada.
Por qué ocurre: los deep links se implementaron para campañas de marketing y nadie consideró el vector de abuso.
Impacto: la superficie es de ingeniería social — la app autenticada ejecuta una acción sensible a partir de un disparador externo. El riesgo real depende de la validación de parámetros y de la confirmación en pantalla, pero la apertura directa de flujos sensibles por enlace es un patrón que debe bloquearse.
Lección: los deep links exigen allowlist de dominios (App Links/Universal Links), validación de parámetros y, para acciones sensibles, confirmación explícita del usuario.
OWASP Mobile Top 10 (2024): M4 (Insufficient Input/Output Validation) — superficie de entrada no validada desde orígenes externos.

4. Por qué el escáner solo no encuentra esto

Los hallazgos anteriores tienen un patrón común: ninguno depende de una vulnerabilidad clásica del backend (SQLi, RCE, XSS). Son fallas de diseño de la app y de lógica de negocio:

Hallazgo	Tipo de prueba que lo encuentra
Secreto hardcoded	Análisis estático del binario (jadx/apkleaks/MobSF) — el escáner de infraestructura no mira el APK
Ausencia de pinning	Prueba manual con proxy + dispositivo real
Almacenamiento inseguro	Análisis dinámico con dispositivo root + Frida
API mobile con controles débiles	Ingeniería inversa + prueba funcional de la API — exige conocer el flujo de la app
Deep links abusables	Prueba manual de intents/URL schemes

Un escaneo automatizado de backend no descarga la app, no descompila, no corre en el dispositivo y no intercepta tráfico. Para la seguridad mobile, el escáner es solo el comienzo — la parte que encuentra los problemas está en el trabajo manual guiado por razonamiento adversarial: "si yo fuera el atacante y tuviera el APK en la mano, ¿qué haría?".

5. Qué incluye un programa de seguridad mobile maduro (checklist práctico)

Con base en el escenario anterior, el mínimo que una fintech debe tener en su programa mobile:

Análisis estático automatizado en el CI (MobSF, semgrep para Android/iOS) — detecta secretos, permisos excesivos, componentes exportados y WebViews inseguros en cada build.
Gestión rigurosa de secretos — ninguna credencial en el binario; secretos en el backend, rotados, con detección de fugas (gitleaks y similares en el repositorio).
Certificate pinning en la app de producción, con plan de rotación y bypass solo en builds de desarrollo.
Almacenamiento seguro — tokens en Keystore/Keychain, datos sensibles no persistidos sin necesidad, FLAG_SECURE en pantallas sensibles (bloqueo de capturas de pantalla).
API mobile tratada como superficie de riesgo propia — mismo rigor de autenticación, rate limiting y mínima exposición de datos; versiones antiguas descontinuadas.
Pentest mobile periódico (en cada release relevante o como mínimo anual) con análisis estático + dinámico + prueba de API — ejecutado por quien conoce el flujo del negocio, no solo por una herramienta.
Capacitación del equipo — los hallazgos más comunes (hardcoded secrets, almacenamiento inseguro) son fallas de hábito, no de tecnología.

6. Por qué contratar un pentest mobile (y no "un escáner")

El valor del pentest mobile no está en "ejecutar una herramienta" — está en la lectura adversarial de un binario que cualquiera puede descargar. Para una fintech, el costo de un hallazgo crítico no remediado se mide en saldo de clientes y en confianza regulatoria: el Banco Central (Bacen) observa la gestión de seguridad de las instituciones de pago, y los incidentes con datos bancarios tienen consecuencias que van más allá de la reparación técnica.

El escenario de PayFlow es laboratorio — pero cada uno de los ocho hallazgos reproduce patrones que se repiten en apps reales del mercado financiero. La diferencia entre la fintech que descubre esto en una prueba y la que lo descubre en un incidente es exactamente el valor del pentest.

Este artículo describe un escenario de laboratorio totalmente ficticio, construido con fines educativos. No se utilizó ningún dato real de clientes. La explotación de vulnerabilidades en sistemas sin autorización explícita es ilegal.