A mobile application pentest checklist is what most finance and fintech buyers ask for when their first PCI DSS or NIS2 audit forces the question. The list looks tidy on paper. What the engagement actually does in practice is less tidy, and the difference is where scanners stop and human testers begin. This post walks through what a mobile pentest covers, mapped to the OWASP Mobile Application Security Project controls, with a concrete attack path through the network layer to show why mobile app security testing is not a button you press.

The framing matters because the underlying numbers are not encouraging. The Zimperium 2025 Global Mobile Threat Report found that “over 60% of iOS and up to 34% of Android apps lack basic code protection,” meaning no obfuscation, anti-tampering, or root-detection controls in the shipped binary. The Promon Q2 2025 App Threat Report recorded “a 200% year-on-year growth in malware families” hitting financial apps over the same period. The attackers are showing up; the apps are not always ready.

What MASVS Controls Cover

CTDefense structures every mobile engagement around the OWASP MASVS standard. MASVS splits the assessment into a set of control categories that each map to a specific class of finding the team chases on the device and against the backend. The categories the team works through on a typical engagement:

• MASVS-STORAGE. What the app writes to disk, how it protects it, and whether a rooted or jailbroken device can read it.
• MASVS-CRYPTO. Which algorithms the app picks, where the keys live, and whether the team can extract them.
• MASVS-AUTH. How the app handles login, session tokens, biometric prompts, and step-up flows.
• MASVS-NETWORK. How traffic between the app and its backend is protected, including certificate pinning and TLS configuration.
• MASVS-PLATFORM. Permissions, IPC, deeplinks, WebView usage, and the surfaces an installed malicious app could reach.
• MASVS-CODE. Third-party SDK risk, debug flags left in release builds, exported components.
• MASVS-RESILIENCE. Anti-tampering, root and jailbreak detection, emulator detection, integrity checks.

Each finding the team raises is tagged to a MASVS control. That makes the fix backlog auditable and gives the security team something concrete to take to a regulator. OWASP MASVS controls are not the engagement’s marketing language; they are its scope document.

Insecure Data Storage on Rooted Devices

The first thing a tester does after installing the app is root or jailbreak the test device, then pull the app’s local data directory. On Android, this means /data/data/<package>; on iOS, the app sandbox under the user container. The team is looking for what the app left behind between sessions.

Common findings in the insecure data storage mobile category:

• Session tokens written to SharedPreferences in cleartext. Anyone with momentary access to a rooted device, or any other app running with root on a compromised handset, can lift the token and replay it against the backend.
• API keys hardcoded in the binary. Tools like apktool and class-dump recover them in seconds. Once they are out, rotation is the only fix.
• PII in SQLite databases without encryption. Customer names, partial card numbers, internal user IDs.
• Sensitive material in the iOS Keychain with the wrong accessibility class. A token stored as kSecAttrAccessibleAlways is readable when the device is locked; the team checks every Keychain item the app writes.

A scanner cannot see most of this. It can flag a missing android:allowBackup="false" attribute in the manifest, but it cannot reason about what the app then chose to write into a backup-eligible directory. The tester opens the database, reads the rows, and reports what was inside.

Certificate Pinning Bypass in Practice

The network section is where the concrete attack path lives. Bypassing the certificate pin is the most common single technique a mobile tester runs, because pinning is the control the app uses to keep an attacker out of the live API traffic. Bypass it once and everything else opens.

The flow on a typical engagement:

1. The team runs the app on a rooted Android device with Frida attached, or on a jailbroken iOS device with Objection or a SSL kill switch tweak.
2. A Frida script hooks the TrustManager (Android) or the equivalent NSURLSession delegate methods (iOS) and returns trust unconditionally. The script also disables OkHttp’s CertificatePinner if the app uses one.
3. The team routes the device’s traffic through Burp Suite or mitmproxy with their own CA. Pinning is now bypassed; every request and response is in the clear.
4. With the traffic visible, the team looks at how the API authenticates each call, what headers the client adds, and what data the server returns that the client never displays. This is where the live findings come from.
5. Once a vulnerable endpoint is identified, the team forges or replays requests directly, often without the app, to confirm the issue is server-side and not just a UI restriction.

This is the attack path most finance and fintech buyers most want to see walked through, because it explains why a passing static scan of the binary does not mean the app is safe in production. The scanner cannot route traffic, cannot hook a method at runtime, and cannot reason about whether the server actually checks the user ID in the URL against the user ID in the bearer token.

Runtime Tampering and RESILIENCE Checks

The MASVS-RESILIENCE category is where the Zimperium statistic above lands directly. If the app has no anti-tampering, no root or jailbreak detection, and no integrity checks, then the pinning bypass above takes minutes, not hours. The team validates the controls that should be there:

• Root and jailbreak detection. The team checks whether the app refuses to run on a compromised device, and if so, how it makes that decision. Detections that rely on a single file path or a single binary name are weak; the team bypasses them with Frida and continues testing.
• Anti-debug and anti-Frida hooks. Whether the app notices a debugger or a Frida agent and reacts.
• Code obfuscation. Whether the team can read the decompiled source clearly enough to find the pinning logic, the crypto routines, and the API keys.
• Integrity checks. Whether the app verifies its own signature at runtime and refuses to run if repackaged.

For deeper technical context on this section, CTDefense has published earlier walkthroughs on how certificate pinning bypass works in practice and on root detection bypass techniques. Both stand up the manual workflow the scanners do not replicate.

The honest assessment from the team: most apps shipped today fail this category on the first pass, which matches what the Zimperium 2025 report (via Help Net Security) notes about enterprise device hygiene, including that “nearly 25 percent of enterprise devices have sideloaded apps” that bypass app-store review entirely. A sideloaded build of the customer app, with the pinning logic patched out, is a realistic threat scenario the engagement should account for.

Mobile API Backend Testing

A common question from buyers: does a mobile pentest test the backend API? Yes. The mobile API backend is in scope on every CTDefense engagement, because the app’s client-side controls are only as strong as the server-side checks behind them. Once traffic is intercepted, the team works the backend the same way a web pentest would, with the mobile context layered on top.

What the team looks for:

• Broken object-level authorization. Can user A read user B’s transactions by changing an ID in a URL or a body parameter? This is the single most common high-severity finding on financial mobile APIs.
• Token scope and lifetime. Does the access token actually expire? Does the refresh-token flow rotate properly, or can a stolen token be used indefinitely?
• Mass assignment. Can the client send fields the server should ignore, and have them stick?
• Endpoint disparity. Does the mobile API expose admin or internal endpoints that the web app does not, often because mobile traffic was assumed to be harder to inspect?
• Rate limiting and abuse controls. Whether the team can brute-force a four-digit PIN, automate account-creation flows, or exhaust an SMS gateway.

A scanner that pointed only at the binary would miss every item on this list. The mobile app and its API are one system; the engagement treats them as one.

How Often Mobile Apps Should Be Pentested

A practical note for the audit-driven buyer. Most frameworks treat a major release or a significant feature change as the natural retest trigger, with annual testing as a baseline rather than a ceiling. For PCI DSS mobile app testing specifically, the requirement to retest after significant changes to in-scope systems applies to the mobile client as much as to the cardholder data environment behind it. Firms shipping multiple releases per quarter benefit from a tighter cadence on the highest-risk surfaces (authentication flows, payment endpoints) and a full pass on each major version.

What This Looks Like as an Engagement

CTDefense’s Mobile Application Pentest follows the MASVS categories above, with a senior tester driving the work on real devices and a written report that maps every finding back to a control and a remediation. The report goes to the security team, the engineering lead, and where relevant the auditor. A structured engagement makes the fix backlog prioritised and auditable, which is what most buyers actually need when their compliance window opens.

Firms in finance, fintech, and the medical sector that have shipped a customer-facing mobile app and have not yet run a formal assessment typically run a structured mobile pentest before their next PCI DSS or NIS2 audit window. The data from this spring suggests waiting is not the safer option.