Mobile App Penetration Testing

What mobile app pentesting covers

Mobile app penetration testing is a structured attempt to find security weaknesses in an iOS or Android application by thinking like an attacker. You decompile the binary, hook into the running process, intercept network traffic, and try to extract data, bypass controls, or abuse functionality.

It differs from automated scanning in one important way: you make decisions. A scanner runs a fixed set of checks. A pentester notices that the app stores an OAuth token in SharedPreferences, then pivots to see whether that token grants access to other users’ data through the API. That chain of reasoning is what automated tools cannot replicate.

A typical engagement covers the app binary, its runtime behavior, the network communication, the backend APIs it calls, and any hardening controls like certificate pinning or root detection. Most clients want both platforms tested, which roughly doubles the effort since iOS and Android have different security models, tooling, and attack surfaces.

The standard timeframe is 5 to 15 working days depending on app size and scope. Small apps with a handful of screens and a REST API take a week. Banking or healthcare apps with complex authentication, biometric integration, and offline functionality take two to three weeks.

Setting up your testing environment

You need a controlled environment where you can decompile, instrument, proxy, and observe the app without restrictions. Here is what that looks like in practice.

Hardware

For Android, a physical rooted device gives the best results. A Pixel phone with Magisk is the standard choice because it has good Frida compatibility and unlockable bootloader. Android emulators work for basic testing but some apps detect emulators and refuse to run. Genymotion is a solid middle ground.

For iOS, you need a jailbroken iPhone. The jailbreak scene is less stable than Android rooting, and newer iOS versions are harder to jailbreak. If you cannot jailbreak, you can still do static analysis and network interception, but runtime hooking becomes very limited. Corellium offers cloud-based jailbroken iOS devices for teams that need consistent access.

Software toolkit

Frida shows up on every mobile pentest. It injects JavaScript into running processes, letting you hook functions, modify return values, and bypass security controls at runtime. If you do mobile pentesting, you will use Frida on every engagement.

Objection wraps Frida with pre-built scripts for common tasks: disabling SSL pinning, dumping keychain contents, exploring the file system, and listing classes. It saves you from writing Frida scripts for routine operations.

Burp Suite handles network interception. Configure the device to route traffic through Burp, install the Burp CA certificate on the device, and you can see every HTTP and HTTPS request the app makes. Pair it with Frida to bypass certificate pinning when the app refuses your proxy certificate.

jadx decompiles Android APKs into readable Java source code. apktool decodes APKs into smali bytecode and resources, which is useful when jadx output is incomplete or when you need to modify and rebuild the app.

MobSF automates the initial scan. Upload the APK or IPA and get a report covering hardcoded secrets, insecure configurations, permissions, and known vulnerable libraries. It handles both static and dynamic analysis and cuts hours off the reconnaissance phase.

Environment setup checklist

1. Root or jailbreak the test device
2. Install Frida server on the device, Frida client on your laptop
3. Install and configure Burp Suite with the device proxy
4. Install Burp CA certificate on the device (system-level for Android 7+)
5. Install jadx, apktool, and objection on your laptop
6. Set up MobSF locally or in Docker for automated scanning
7. Prepare a note-taking system with screenshot support (you will need it for the report)

Static analysis phase

Static analysis happens before you run the app. You are looking at the decompiled code, resources, and configuration to understand how the app works and where the weak points are.

Decompilation

Pull the APK from the device with adb pull or download it from the app store. For iOS, extract the IPA from a jailbroken device using tools like frida-ios-dump or from iTunes backups. Run the binary through jadx (Android) or class-dump and Hopper (iOS) to get readable code.

Spend time reading the code before you start looking for bugs. Understand the app architecture: which network library it uses, how it handles authentication, where it stores data, what third-party SDKs are included. This context makes everything else faster.

Hardcoded secrets

Search the decompiled code for API keys, encryption keys, Firebase URLs, AWS credentials, and OAuth client secrets. String searches for patterns like AIza, AKIA, sk_live, -----BEGIN, and firebase catch most of them. This is almost always productive. Developers still embed secrets in mobile binaries despite years of warnings.

Insecure data storage

Check how the app stores data locally. Look for SharedPreferences (Android) or NSUserDefaults/plist files (iOS) storing sensitive values in plaintext. Check SQLite databases for unencrypted credentials or personal data. Look for sensitive information written to log files. Oversecured covers 175+ Android vulnerability categories including storage-related issues.

Permissions and configuration

Review AndroidManifest.xml or Info.plist for excessive permissions, exported components, backup enabled flags, and debug settings. An exported Android activity that accepts arbitrary intents is a common finding. An iOS app with NSAppTransportSecurity exceptions allowing HTTP traffic is another.

Third-party libraries

Identify all included libraries and check them against vulnerability databases. Outdated versions of popular SDKs (OkHttp, Retrofit, AFNetworking) may contain known security issues. MobSF automates this check, but manual review of the dependency tree catches things scanners miss.

Dynamic analysis phase

Dynamic analysis means running the app and watching what it actually does at runtime.

Runtime hooking with Frida

Attach Frida to the running app process and start hooking interesting functions. Hook encryption and decryption methods to see plaintext data before it gets encrypted. Hook authentication functions to understand the login flow. Hook certificate validation callbacks to see how pinning is implemented, and root or jailbreak detection checks to understand what triggers them.

Objection makes this easier. Run objection explore after attaching to the process, and you get an interactive shell where you can dump the keychain, list loaded classes, search for specific method names, and disable common security controls with single commands.

Network interception

Route the device traffic through Burp Suite and exercise every feature of the app. Log in, browse content, make transactions, change settings. Look for sensitive data in request parameters, headers, and response bodies. Check whether the app falls back to HTTP when HTTPS fails. Test whether session tokens are properly invalidated on logout.

If the app implements certificate pinning, your proxy will fail. Use Frida or objection to bypass the pinning first, then resume traffic interception. The ease of bypass tells you something about the implementation quality.

SSL pinning bypass

Most pinning implementations can be bypassed with objection’s android sslpinning disable or ios sslpinning disable commands. If that does not work, you need to find the specific pinning library (OkHttp CertificatePinner, TrustKit, custom implementations) and write a targeted Frida script. Document the bypass method and difficulty level in your report.

API testing

The mobile app is a client for backend APIs. Once you can intercept traffic, test the APIs directly. Check for broken object-level authorization (can you access another user’s data by changing an ID?), broken authentication (can you reuse expired tokens?), and excessive data exposure (does the API return more data than the app displays?). This overlap with API security testing often produces the highest-severity findings.

iOS-specific testing considerations

iOS has a tighter security model than Android, which changes what you test and how.

Keychain storage. iOS Keychain is the proper place for secrets, but the protection class matters. Items stored with kSecAttrAccessibleAlways are readable even when the device is locked. Check what protection class the app uses and whether keychain items persist after app deletion.

App Transport Security (ATS). ATS enforces HTTPS by default on iOS. Apps can add exceptions in Info.plist. Check for NSAllowsArbitraryLoads set to true, which disables ATS entirely, or domain-specific exceptions that weaken TLS requirements.

Binary protections. Check for PIE (position-independent executable), ARC (automatic reference counting), and stack canaries. Missing PIE makes exploitation easier. The otool command checks these flags on the Mach-O binary.

URL scheme hijacking. iOS apps register custom URL schemes (myapp://). If multiple apps register the same scheme, iOS does not guarantee which one handles the URL. This can lead to authentication token theft when deep links carry sensitive parameters.

Android-specific testing considerations

Android’s more open architecture means a bigger attack surface.

Exported components. Android apps declare activities, services, broadcast receivers, and content providers in the manifest. If these are exported (explicitly or by default when intent filters are present), any app on the device can interact with them. Test each exported component by sending crafted intents and observing the behavior.

Content provider leakage. Content providers that expose data through content:// URIs without proper permission checks let other apps query sensitive data. Check for path traversal in content provider implementations too.

WebView risks. Android WebViews with JavaScript enabled and JavaScript interfaces (addJavascriptInterface) are high-risk targets. An XSS vulnerability in web content loaded into such a WebView gives the attacker access to native Android functionality. Check whether the app loads remote content in WebViews with JavaScript bridges.

Backup and debug flags. android:allowBackup="true" lets anyone with USB access extract app data through adb backup. android:debuggable="true" in a production build lets attackers attach a debugger. Both are common findings.

Shared storage. Android apps writing to external storage (SD card) put data where any app with storage permission can read it. Check what the app writes to external storage and whether it includes sensitive information.

Common findings and severity ratings

After a few dozen mobile pentests, patterns emerge. Here are the findings you will see repeatedly and how they typically rate.

Hardcoded API keys and secrets. High or Critical depending on what the key grants access to. An AWS key with admin privileges is critical. A Google Maps API key is informational. Always demonstrate what the exposed key can actually do.

Insecure local data storage. Medium to High. Authentication tokens in plaintext SharedPreferences on Android are high. Cached non-sensitive UI state in a plist is low. Context determines the severity.

Missing or bypassable certificate pinning. Medium. The app communicates securely over TLS, but a determined attacker on the same network can intercept traffic. Rate it higher if the app handles financial or health data.

Excessive permissions. Low to Medium. An app requesting camera, microphone, contacts, and location when it only needs network access. The risk depends on what the app could theoretically do with those permissions.

Debug mode enabled in production. Medium. Allows attaching a debugger and inspecting memory, variables, and control flow at runtime.

Weak root or jailbreak detection. Low to Medium. If the app detects rooted devices but the detection is bypassable in under a minute with a standard Frida script, the control adds little value. Rate it based on the sensitivity of what the app protects.

Insecure deeplink handling. Medium to High. Deep links that trigger actions without validation can lead to account takeover or data theft. The severity depends on what actions the deep link can trigger.

Writing the report

The report is the deliverable. A pentest that finds ten critical issues but communicates them poorly is worth less than a pentest that finds five issues and explains them clearly.

Structure that works

Start with an executive summary. One page, no jargon, written for someone who will not read the rest. State how many findings at each severity level, the overall risk level, and the top three things to fix first.

Follow with a methodology section explaining what you tested, what tools you used, what was in and out of scope, and the testing timeframe. This establishes credibility and sets expectations.

The findings section is the core. Each finding needs a title, severity rating, affected component, description of the issue, proof of concept with screenshots, business impact explanation, and remediation recommendation. Include the OWASP MASVS or Mobile Top 10 mapping for each finding.

Writing effective findings

Be specific. “Insecure data storage” is not a finding title. “Authentication Token Stored in Plaintext SharedPreferences” is. Include the exact file path, the exact data stored, and the exact steps to reproduce.

Always include a proof of concept. A screenshot of the extracted token, a Frida script that bypasses the control, a curl command that demonstrates the API vulnerability. If you cannot prove it, downgrade the severity or drop it.

Write remediation recommendations that a developer can act on. “Use encrypted storage” is too vague. “Migrate from SharedPreferences to Android EncryptedSharedPreferences (part of Jetpack Security library) with AES-256-GCM encryption” tells them exactly what to do.

Tools and templates

Most pentesters maintain their own report templates. If you need a starting point, the OWASP MASTG provides checklists organized by MASVS category that map directly to report findings. NowSecure and AppKnox generate automated reports that some teams use as a baseline for manual assessments.

FAQ

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.