Mobile Security in Fintech: What a Pentest Finds in the App Your Scanner Never Sees

Category: Mobile Security | Pentest | Fintech Level: Intermediate Environment: Controlled laboratory — fully anonymized scenario, no real client data

---

Introduction

Your banking app is on the Play Store with 4.8 stars. The engineering team does code review, the pipeline runs SAST on every push and the backend went through an automated scan at the last release. Even so, when a mobile pentest begins, the first thing the tester finds usually surprises: the most serious problems are not in the backend — they are in the app you published.

Fintechs process exactly the kind of asset adversaries pursue most: money, banking data, session tokens and PII at scale. The smartphone has become the main interface of that flow, and mobile security has a unique characteristic: the app's code is in the attacker's pocket. Unlike the backend, which you protect behind firewall and WAF, the APK/IPA is distributed to millions of devices — anyone can download, decompile and study your app like reading an open book.

This material is preventive and describes, in an anonymized laboratory scenario, what a mobile pentest found in a fictitious fintech ("PayFlow") — and why each finding represents a real risk for any company that moves money through an app.

---

1. Why mobile security is different (the physics of the problem)

Before the findings, it is worth understanding why the app demands its own approach:

1. The attacker has the binary. Backend is a black box; app is a white box. With jadx, apktool or MobSF, anyone turns an APK into readable code in minutes. A secret that lives in the app is not a secret — it is a countdown.
2. The device is hostile. The app runs in an environment the user controls: rooted, with hooking (Frida), with a proxy intercepting traffic. If the app trusts the device, the attacker controls the app.
3. The mobile API is a parallel surface. Many fintechs keep app-specific endpoints with weaker controls than the web ones — and old API versions stay live years later.
4. The damage is direct. Session token leakage, authentication bypass or an exposed API key in a fintech mean access to balance, transfers and banking data — not just "infrastructure exposure".

The OWASP Mobile Top 10 (2024) organizes well what repeats most in real tests: improper credential usage (M1), insecure communication (M5), insecure authentication/authorization (M3), insecure data storage (M9) and insufficient binary protections (M7) — exactly the patterns the findings below reproduce.

---

2. The laboratory scenario: the "PayFlow" fintech

To show the complete flow, we used a fictitious laboratory scenario: PayFlow, a payments fintech with 2 million active users, Android and iOS apps, moving Pix, cards and digital accounts. It hired a mobile pentest with the following guidance: test the app as a real adversary would — download the APK, decompile, analyze statically and then attack the API behind the app with a proxy.

The result: eight findings, all with reproduction, all classified by the real impact for the business. Below, the five most representative ones.

---

3. The findings (anonymized scenario)

Finding 1 — [CRITICAL] API key and signing secret hardcoded in the APK

In the APK static analysis (jadx + apkleaks), the tester found a third-party payments service API key and the secret used to sign JWT tokens embedded in the code, in a configuration class.

• Reproduction: extraction of the APK from the Play Store → decompilation → strings/constants in plain text.
• Why it happens: the team needed a simple way to authenticate the app against the service and "hid" the secret in the client code, believing obfuscation was enough.
• Impact: with the signing secret, an attacker forges JWT tokens and impersonates any user — including administrative users, if the backend does not differentiate the app token from the admin token. The third-party key allows spending the payments service's credit on PayFlow's behalf.
• Lesson: a secret that needs to live in the backend cannot live in the app. Any embedded credential is, by definition, public.
• OWASP Mobile Top 10 (2024): M1 (Improper Credential Usage) + M7 (Insufficient Binary Protections) — obfuscation is not access control.

Finding 2 — [HIGH] No certificate pinning: traffic interceptable via proxy

The app only validated the operating system's certificate chain — no certificate pinning. The tester was able to intercept traffic through two paths: installing Burp Suite's CA on the device worked because the app trusted user CAs (common in development builds or with a permissive networkSecurityConfig); in modern Android apps (targetSdk ≥ 24), which do not trust user CAs by default, the real path is Frida bypass.

• Reproduction: proxy on the network → CA installation (development builds/permissive networkSecurityConfig) or Frida bypass → app traffic decoded in Burp.
• Why it happens: pinning makes development harder (staging certificates, CI testing) and the team postponed implementation.
• Impact: in a real scenario, the same intercepted traffic contains session tokens and payloads with banking data. Pinning is not an absolute defense (an attacker with device access uses Frida to get around it), but it raises the attack cost and prevents passive interception on public networks — the most common entry point.
• Lesson: pinning is basic hygiene for an app that moves money; without it, the app depends entirely on the OS's TLS.
• OWASP Mobile Top 10 (2024): M5 (Insecure Communication).

Finding 3 — [HIGH] Session tokens and banking data stored in plain text on the device

Dynamic analysis (rooted device + Frida) revealed that the app kept the session token and the last viewed statement in SharedPreferences and in SQLite files in plain text — no encryption, no Keychain/Keystore.

• Reproduction: browse the app → inspect /data/data/<package>/shared_prefs and the local SQLite.
• Why it happens: storing the token in persistent memory was the quick solution to keep the user logged in without re-authenticating on every open.
• Impact: a compromised device (malware/root), or a lost/stolen handset without screen lock/FBE or with allowBackup=true (extraction via adb backup), delivers the session token — and, with it, account access without needing a password. Banking data stored locally amplifies the damage of a simple phone theft.
• Lesson: tokens must live in the OS's secure storage (Keystore/Keychain), with short lifetimes; sensitive data should not be persisted on the device without need — and, if it must, encrypted with a key derived from the Keystore.
• OWASP Mobile Top 10 (2024): M9 (Insecure Data Storage).

Finding 4 — [HIGH] Mobile API endpoints with weaker controls than the web ones

The app talked to a dedicated API (api-mobile.payflow.app) that did not enforce the same controls as the web API: missing rate limiting, no app version validation and responses with more data than the screen needs (e.g., the balance endpoint also returned the full transaction history and the user's full CPF).

• Reproduction: static analysis revealed the endpoint; the proxy showed the full response payload.
• Why it happens: the mobile API was created later, by another team, in a rush to launch — and nobody reviewed whether the web API's controls applied to it.
• Impact: the absence of rate limiting opens the door to account enumeration and brute-force attacks; the data excess in responses turns a legitimate endpoint into an exfiltration source for an attacker with a leaked token (or in an unauthorized access scenario).
• Lesson: a mobile API is not a different API — it is the same risk surface, with the aggravating factor of being easily discovered from the app itself.
• OWASP Mobile Top 10 (2024): M3 (Insecure Authentication/Authorization) — missing rate limiting and data excess in responses aggravate M3.

Finding 5 — [MEDIUM] Manipulable deep links (opening sensitive screens without origin validation)

The app registered deep links (payflow://transferencia?valor=...) and opened them without validating the intent/URL scheme origin. In an attack scenario, a malicious link triggered by SMS or a compromised website could open pre-filled transfer screens inside the authenticated app.

• Reproduction: adb shell am start -a android.intent.action.VIEW -d "payflow://transferencia?valor=9999" on a device with the app logged in.
• Why it happens: deep links were implemented for marketing campaigns and nobody considered the abuse vector.
• Impact: the surface is social engineering — the authenticated app performs a sensitive action from an external trigger. Real risk depends on parameter validation and on-screen confirmation, but opening sensitive flows directly via link is a pattern that must be blocked.
• Lesson: deep links require a domain allowlist (App Links/Universal Links), parameter validation and, for sensitive actions, explicit user confirmation.
• OWASP Mobile Top 10 (2024): M4 (Insufficient Input/Output Validation) — unvalidated entry surface from external origins.

---

4. Why the scanner alone does not find this

The findings above share a common pattern: none of them depends on a classic backend vulnerability (SQLi, RCE, XSS). They are app design and business logic flaws:

An automated backend scan does not download the app, does not decompile, does not run on the device and does not intercept traffic. For mobile security, the scanner is just the beginning — the part that finds the problems is the manual work guided by adversarial reasoning: "if I were the attacker with the APK in hand, what would I do?".

---

5. What a mature mobile security program includes (practical checklist)

Based on the scenario above, the minimum a fintech should have in its mobile program:

1. Automated static analysis in CI (MobSF, semgrep for Android/iOS) — catches secrets, excessive permissions, exported components and insecure WebViews on every build.
2. Rigorous secret management — no credential in the binary; secrets in the backend, rotated, with leak detection (gitleaks and similar in the repository).
3. Certificate pinning in the production app, with a rotation plan and bypass only in development builds.
4. Secure storage — tokens in Keystore/Keychain, sensitive data not persisted without need, FLAG_SECURE on sensitive screens (screenshot blocking).
5. Mobile API treated as its own risk surface — same authentication rigor, rate limiting and minimal data exposure; old versions discontinued.
6. Periodic mobile pentest (at every relevant release or at least annually) with static + dynamic analysis + API testing — performed by someone who understands the business flow, not just by a tool.
7. Team training — the most common findings (hardcoded secrets, insecure storage) are habit failures, not technology failures.

---

6. Why hire a mobile pentest (and not "a scanner")

The value of a mobile pentest is not in "running a tool" — it is in the adversarial reading of a binary anyone can download. For a fintech, the cost of an unremediated critical finding is measured in customer balance and regulatory trust: the Central Bank of Brazil (Bacen) oversees the security management of payment institutions, and incidents involving banking data have consequences that go beyond technical repair.

The PayFlow scenario is a laboratory — but each of the eight findings reproduces patterns that repeat in real apps in the financial market. The difference between the fintech that discovers this in a test and the one that discovers it in an incident is exactly the value of the pentest.

---

This article describes a fully fictitious laboratory scenario, built for educational purposes. No real client data was used. Exploiting vulnerabilities in systems without explicit authorization is illegal.