Mobile app penetration testing is a hands-on security test of your Android and iOS apps, where testers attack the app the way a real adversary would: they pull apart the binary, inspect what it stores on the phone, intercept its network traffic and abuse the backend APIs it talks to. The goal is to find exploitable weaknesses before launch, before a bank or partner security review, or before an audit, and to give your developers clear fixes.
A good test follows the OWASP Mobile Top 10 for risk coverage, OWASP MASVS for the security requirements and OWASP MASTG for the test methodology. This guide explains what is tested on each platform, how the process runs, a practical checklist, how to prepare your builds and what drives the cost.
Key takeaways
- Mobile app penetration testing covers four layers: the app binary, data stored on the device, network traffic and the backend APIs behind the app.
- Automated scanners such as MobSF are a useful first pass, but they cannot prove business-logic flaws, broken authorisation or account takeover. Manual testing can.
- The OWASP Mobile Top 10 (2024) defines the main risk categories; OWASP MASVS v2 sets the controls and OWASP MASTG describes how to test them.
- Android and iOS need separate testing: APK reverse engineering, exported components and root detection on one side; IPA analysis, Keychain, ATS and jailbreak detection on the other.
- Give testers both builds, a non-obfuscated debug build if possible, test accounts for every role and a stable staging backend.
What mobile app penetration testing actually covers
Most mobile security issues are not in the screens users see. A complete mobile application penetration testing engagement looks at four layers.
- The app binary: decompiling the APK or IPA to find hardcoded API keys, secrets, hidden endpoints, debug flags, weak cryptography and logic that should never run on the client.
- Local storage: checking shared preferences, plist files, SQLite databases, caches, logs, screenshots and the Keychain or Keystore for tokens, personal data or card details stored insecurely.
- Network traffic: intercepting requests through a proxy such as Burp Suite to confirm TLS is enforced, certificates are validated and certificate pinning (if used) actually holds.
- Backend APIs: testing the APIs the app calls for broken authentication, IDOR (accessing another user's data by changing an ID), missing rate limits and business-logic abuse. In practice, this is where many of the most serious findings show up.
Why a MobSF scan alone is not enough
MobSF (Mobile Security Framework) is a useful open-source tool for automated static and dynamic analysis. It quickly flags insecure manifest settings, hardcoded strings and risky permissions, and testers often start with it.
But a scanner reports patterns, not proven impact. It cannot log in as one customer and pull another customer's transactions, or chain a weak OTP flow into account takeover. It also produces false positives that waste developer time. Mobile app security testing that a bank or auditor will accept needs manual verification of every finding, with proof and a fix. If you are new to the terms, our guide on what VAPT is explains the difference between a vulnerability assessment and a penetration test.
OWASP Mobile Top 10 (2024): what testers check
The OWASP Mobile Top 10 is the most widely referenced list of mobile risk categories. The 2024 edition replaced the 2016 list and is what reports are now expected to map to.
| Category | What testers check |
|---|---|
| M1: Improper Credential Usage | Hardcoded API keys, secrets or passwords in the binary; credentials stored or sent insecurely |
| M2: Inadequate Supply Chain Security | Third-party SDKs and libraries with known vulnerabilities or excessive data access; build and signing integrity |
| M3: Insecure Authentication/Authorization | OTP and login bypass, weak session handling, client-side role checks, IDOR on backend APIs |
| M4: Insufficient Input/Output Validation | Injection through app inputs and deep links, WebView issues, unsafe handling of data from intents or URL schemes |
| M5: Insecure Communication | Cleartext HTTP, weak TLS, missing certificate validation, pinning that is absent or easily bypassed |
| M6: Inadequate Privacy Controls | Personal data in logs, analytics or backups; over-collection; data shared with third parties without need |
| M7: Insufficient Binary Protections | Ease of reverse engineering and tampering, missing obfuscation, weak root or jailbreak detection |
| M8: Security Misconfiguration | Debuggable builds, backup enabled, exported components, permissive ATS or network security config |
| M9: Insecure Data Storage | Tokens, PII or card data in plain files, databases, caches, screenshots or the clipboard |
| M10: Insufficient Cryptography | Weak or custom algorithms, hardcoded keys, poor key storage, predictable random values |
OWASP MASVS and MASTG: the standard behind the test
The Top 10 tells you what usually goes wrong. OWASP MASVS (Mobile Application Security Verification Standard) tells you what "secure" should look like. Version 2 groups its controls as follows:
- MASVS-STORAGE: sensitive data is stored securely on the device.
- MASVS-CRYPTO: cryptography is used correctly and keys are protected.
- MASVS-AUTH: authentication and authorisation are handled securely, mainly on the backend.
- MASVS-NETWORK: data in transit is protected, including certificate validation and pinning where needed.
- MASVS-PLATFORM: the app uses platform features (IPC, WebViews, deep links, UI) safely.
- MASVS-CODE: dependencies are maintained and input from untrusted sources is validated.
- MASVS-RESILIENCE: the app resists reverse engineering and tampering.
- MASVS-PRIVACY: the app minimises and protects user data and is transparent about it.
OWASP MASTG (Mobile Application Security Testing Guide) is the companion manual, with concrete Android and iOS test cases for each MASVS control. If a vendor claims to follow OWASP MASVS and MASTG, ask how their report maps findings to these controls.
Android app penetration testing
Android apps ship as APK or AAB packages, which are relatively easy to decompile. Android app penetration testing usually includes:
- Reverse engineering: decompiling with jadx to read near-source Java or Kotlin, and apktool to decode resources and the AndroidManifest.xml. Testers look for secrets, hidden endpoints, test flags and client-side business logic.
- Exported components: activities, services, broadcast receivers and content providers that are exported without proper permissions can be called by any other app on the device, sometimes leaking data or skipping the login screen.
- Insecure storage: SharedPreferences, SQLite databases, external storage and logcat output are checked for tokens and personal data. Proper use of the Android Keystore is verified.
- Manifest, WebViews and deep links: android:debuggable, android:allowBackup, cleartext traffic, JavaScript interfaces and intent handling a malicious link could abuse.
- Root detection and tamper checks: whether the app detects rooted devices and repackaging, and how easily those checks are bypassed.
iOS app penetration testing
iOS is more locked down, but apps are not secure by default. iOS app penetration testing covers:
- IPA analysis: App Store builds are encrypted, so testers work with a decrypted IPA or a build you provide. They inspect the binary, embedded frameworks, Info.plist, URL schemes and universal links.
- Keychain: the Keychain is the right place for secrets, but the accessibility attribute matters. Testers check that tokens are not readable when the device is locked or restored from backup when they should not be.
- Other storage: NSUserDefaults, plists, Core Data, caches, the pasteboard and background screenshots.
- App Transport Security (ATS): exceptions such as NSAllowsArbitraryLoads weaken TLS protections and need justification.
- Jailbreak detection: whether the app detects jailbroken devices and runtime hooking, and how much effort a bypass takes.
Preparing for a bank, NBFC or enterprise partner security review? See how our mobile application penetration testing covers Android, iOS and the APIs behind them, with manually verified findings and a free retest.
Dynamic testing: Frida, Objection, SSL pinning and the API layer
Dynamic testing shows what the app actually does on a rooted Android device or jailbroken iPhone, instrumented at runtime.
- Frida is a dynamic instrumentation toolkit that lets testers hook functions while the app runs: read decrypted values, change return values, or switch off client-side checks.
- Objection, built on Frida, speeds up common tasks such as exploring the app's storage, dumping the Keychain and testing root, jailbreak and pinning controls.
SSL pinning bypass testing checks how well certificate pinning holds up. Pinning makes interception harder, but an attacker can usually bypass it on a device they control, so testers bypass it deliberately to reach the API traffic. If your security depends on pinning alone, the backend is not secure enough.
Once traffic is visible, the API testing behind the app starts. Testers modify requests to check object-level authorisation, privilege escalation, OTP and reset flows, rate limiting, payment logic and data exposed in responses. This overlaps heavily with API pentesting; our guide to API security testing covers that layer in more depth.
Mobile app penetration testing process, step by step
- Scoping: agree platforms, versions, user roles, in-scope APIs and environment.
- Static analysis: decompile the APK and IPA, run tools such as MobSF, and review manifests, configs and libraries.
- Dynamic analysis: run the app on test devices, inspect storage, hook it with Frida and Objection, and test resilience controls.
- Traffic and API testing: intercept traffic and manually test authentication, authorisation and business logic.
- Verification: confirm each issue with a proof of concept and remove false positives.
- Reporting: findings rated by severity (commonly with CVSS), mapped to OWASP Mobile Top 10 and MASVS, with evidence and step-by-step fixes.
- Retest: testers verify your fixes and issue an updated report you can share with partners.
Mobile app security testing checklist
Use this mobile app security testing checklist to self-review before a test, or to judge whether a vendor's scope is complete.
- No API keys, secrets or credentials hardcoded in the APK or IPA.
- Release builds are not debuggable; Android backup is off for sensitive data; only necessary components are exported.
- Tokens live in the Keystore or Keychain, not in plain files, and no PII or OTPs appear in logs, caches or screenshots.
- All traffic uses TLS with proper certificate validation; ATS and network security config have no unjustified exceptions.
- Every API enforces authorisation on the server for each object and action.
- OTP, login and password reset flows have rate limits, expiry and lockout; sessions are revoked on logout.
- Third-party SDKs are up to date and their data collection is reviewed.
- Pinning, root and jailbreak detection and obfuscation are in place where your risk profile needs them.
How to prepare for a mobile app pentest
Good preparation gives deeper results. Before testing starts, share:
- Builds: the latest APK (or AAB) and IPA (or a TestFlight invite). If possible, add a non-obfuscated debug build, so testers spend time on real issues rather than unpacking obfuscation. The release build is still tested for resilience.
- Test accounts: at least two accounts per role (for example customer, merchant, admin) so cross-account access can be tested, plus a way to receive test OTPs.
- Backend environment: a stable staging or UAT environment that mirrors production, with test data and test payment modes.
- Documentation: API docs or a Postman collection, key business flows, a technical contact and any areas you are worried about.
What does mobile app penetration testing cost in India?
Cost depends on the number of platforms, the size and complexity of the app, the number of user roles, how many backend APIs are in scope and whether you need a retest report for a partner. At Xtreme InfoSec, mobile app penetration testing starts from ₹30,000, with a fixed quote after scoping. Timelines also depend on scope and are confirmed in the quote. For a quick idea for your own app, use our VAPT cost estimator.
When comparing vendors, ask whether findings are manually verified, whether both platforms and the APIs are included, and whether a retest is included. Some regulators and clients ask for a CERT-In-empanelled auditor, so check your own requirement before you choose.
Frequently asked questions
What is the difference between mobile app security testing and mobile app penetration testing?
Mobile application security testing is the broad term and can include automated scans, code review and penetration testing. Penetration testing is the manual, attacker-style part that tries to exploit weaknesses and prove real impact. Partners and auditors usually want a penetration test report, not only a scan output.
Do we need to test Android and iOS separately?
Yes. The two platforms store data differently, use different security controls and are often built by different teams or with different libraries. The backend APIs are shared, so they are usually tested once, but each app binary needs its own analysis.
Is OWASP MASVS a certification?
OWASP MASVS is a security standard, not a certificate issued by OWASP. A penetration test report can show how your app measures up against MASVS controls. Some industry programmes build formal assessments on top of MASVS, so check what your partner actually asks for.
How often should a mobile app be pentested?
At minimum before a major launch, after significant changes to login, payments or APIs, and at the interval your partners or regulators require, which is often yearly. Fintech and healthtech apps that ship frequently benefit from testing major releases.
Get your Android and iOS apps tested before your next review
Xtreme InfoSec runs manual, expert-led penetration testing of Android and iOS apps and the APIs behind them, following OWASP MASVS and MASTG. Every engagement includes an OWASP-mapped report with step-by-step fixes and a free retest after your team fixes the issues.