Mobile Application Security: MAST, MASVS & Mobile Pentesting (2026)

Written by Suphi Cankurt
Why mobile security matters
Mobile applications handle some of the most sensitive data people generate. Banking apps store financial credentials. Health apps track medical records. Authentication apps generate one-time passwords that protect other accounts. When a mobile app has a security flaw, the impact is personal and direct.
The threat model for mobile apps is fundamentally different from web applications. With a web app, the server is the trust boundary. An attacker interacts with your API endpoints, but they never touch the server-side code. With a mobile app, you ship the binary to the user’s device. Attackers can decompile it, instrument it at runtime, inspect its local storage, and intercept its network traffic. The app runs in hostile territory.
Mobile malware detections have grown year over year. Zimperium’s 2024 Global Mobile Threat Report found that 80% of phishing sites specifically target mobile devices. Regulatory pressure is also increasing. PCI DSS 4.0 requires security testing of payment-related mobile applications. HIPAA applies to any mobile app handling protected health information. The EU’s CRA will apply to connected apps sold in the European market by 2027.
Yet mobile security testing remains an afterthought in many AppSec programs. Teams that run SAST and DAST on their web applications often skip their mobile apps entirely. That gap is worth closing.
Mobile attack surface
Mobile apps expose a broader attack surface than most teams realize. The risks extend well beyond the backend API.
Local data storage. iOS apps can write to the Keychain, UserDefaults, Core Data, and the file system. Android apps use SharedPreferences, the Android Keystore, SQLite databases, and internal/external storage. Developers routinely store session tokens, API keys, and personal data in places that a rooted or jailbroken device can read. A surprising number of apps store credentials in plaintext SharedPreferences.
Network communication. Mobile apps communicate over networks the developer does not control. Public Wi-Fi, cellular connections, and VPN tunnels all present interception opportunities. Certificate pinning prevents man-in-the-middle attacks, but it must be implemented correctly. Many apps rely on the platform’s default certificate validation, which can be bypassed on rooted devices by installing a custom CA certificate.
Binary protections. Unlike web apps, mobile apps distribute their compiled code to end users. Attackers can decompile Android APKs with Jadx in seconds. iOS binaries require more effort but are not immune. Without obfuscation and anti-tampering protections, attackers can reverse engineer proprietary logic, extract API keys, and modify the app’s behavior. Guardsquare and similar tools add these protections.
Inter-process communication. Android’s Intent system and iOS’s URL schemes allow apps to communicate with each other. Misconfigured exported activities, deep links without validation, and overly permissive intent filters create attack vectors. An attacker can craft a malicious intent that triggers unintended behavior in a vulnerable app.
Third-party SDKs. Mobile apps often embed advertising SDKs, analytics frameworks, crash reporters, and social login libraries. Each SDK has its own permissions, data collection practices, and potential vulnerabilities. A compromised ad SDK can access location data, device identifiers, and clipboard contents. The app developer is responsible for the security behavior of every SDK they include.
OWASP Mobile Top 10
OWASP maintains a Top 10 list specifically for mobile application risks. The 2024 revision reflects current attack patterns against iOS and Android apps.
| # | Risk | Description |
|---|---|---|
| M1 | Improper Credential Usage | Hardcoded credentials, insecure storage of API keys and tokens |
| M2 | Inadequate Supply Chain Security | Vulnerable or malicious third-party SDKs and libraries |
| M3 | Insecure Authentication/Authorization | Weak login mechanisms, missing session management, broken access controls |
| M4 | Insufficient Input/Output Validation | Injection attacks through intents, deep links, and user input |
| M5 | Insecure Communication | Missing or improperly implemented TLS, no certificate pinning |
| M6 | Inadequate Privacy Controls | Excessive data collection, PII leakage, missing consent mechanisms |
| M7 | Insufficient Binary Protections | No obfuscation, missing anti-tampering, absent root/jailbreak detection |
| M8 | Security Misconfiguration | Debug mode enabled in production, overly permissive manifest, backup flags |
| M9 | Insecure Data Storage | Sensitive data in plaintext files, unencrypted databases, clipboard exposure |
| M10 | Insufficient Cryptography | Weak algorithms, hardcoded keys, improper key management |
These risks differ meaningfully from the web OWASP Top 10. Web security focuses on server-side injection, broken access control, and misconfiguration. Mobile security centers on the device itself: how data is stored locally, whether the binary can be reverse-engineered, and how the app communicates over untrusted networks. There is overlap in authentication and input validation, but the attack techniques are platform-specific.
The Mobile Top 10 provides a useful checklist for initial scans. Most automated tools like MobSF and NowSecure map their findings to these categories. But the list is a starting point, not a finish line. Business logic flaws, platform-specific misconfigurations, and complex authentication flows require manual analysis beyond what any automated checklist covers.
MASVS and MASTG
OWASP provides two companion resources that form the backbone of structured mobile security testing: the Mobile Application Security Verification Standard (MASVS) and the Mobile Application Security Testing Guide (MASTG).
MASVS: The requirements
MASVS defines what to verify. It organizes security requirements into categories: storage, cryptography, authentication, network, platform interaction, code quality, and resilience. Each requirement specifies a concrete, testable security control.
The standard defines two verification levels. MASVS-L1 covers baseline security for all mobile apps. It includes requirements like encrypting sensitive data at rest, validating TLS certificates, and not logging sensitive information. MASVS-L2 adds defense-in-depth controls for apps handling high-value transactions or sensitive personal data. L2 adds requirements like certificate pinning, root/jailbreak detection, and anti-debugging protections.
MASVS works as both a design checklist and an audit framework. Development teams can reference it during design reviews to ensure they address each requirement. Security testers use it as a structured checklist during assessments to ensure coverage.
MASTG: The testing guide
MASTG tells you how to test each MASVS requirement. It is a hands-on manual with specific techniques, tool commands, and expected results for both iOS and Android. For the MASVS requirement “sensitive data is not stored unencrypted,” MASTG provides step-by-step instructions for checking Keychain entries on iOS and SharedPreferences files on Android.
The guide covers setup (lab environment, device preparation, proxy configuration), static analysis techniques (decompilation, string extraction, binary inspection), dynamic analysis techniques (Frida scripts, runtime hooking, network interception), and platform-specific testing for each MASVS category.
For any team doing mobile pentesting, MASTG is the reference manual. Use MASVS to define the scope of your assessment, then follow MASTG’s test cases to execute it.
iOS vs Android security testing
Both platforms share the same high-level risk categories, but the implementation details and testing techniques diverge significantly.
iOS security model
iOS apps run in a strict sandbox. Each app has its own file system container and cannot access other apps’ data without explicit user permission. The Keychain provides encrypted storage for credentials and sensitive tokens. App Transport Security (ATS) enforces TLS by default. Code signing ensures that only Apple-approved binaries run on non-jailbroken devices.
Testing iOS apps requires specific tooling. You need a jailbroken device or a patched IPA to bypass code signing. Frida attaches to iOS processes for runtime instrumentation. Objection wraps Frida with pre-built scripts for common tasks like bypassing SSL pinning, dumping the Keychain, and disabling jailbreak detection. Binary analysis uses Hopper, Ghidra, or class-dump to inspect Objective-C and Swift code.
Android security model
Android’s security model relies on Linux user isolation. Each app runs as a separate Linux user with its own UID. The Android Keystore provides hardware-backed key storage on supported devices. SharedPreferences stores key-value pairs in XML files that are private to the app by default, but accessible on rooted devices.
Android testing is more accessible than iOS because APK files are straightforward to decompile. Jadx converts DEX bytecode back to readable Java source. APKTool reconstructs the full project structure including the manifest, resources, and smali code. Frida works on Android just as it does on iOS. For network interception, you install a custom CA certificate on the device and route traffic through Burp Suite or mitmproxy.
Platform comparison
| Aspect | iOS | Android |
|---|---|---|
| Secure storage | Keychain | Android Keystore / EncryptedSharedPreferences |
| Default TLS enforcement | App Transport Security (strict by default) | Network Security Config (permissive by default until API 28) |
| Binary analysis | Hopper, Ghidra, class-dump | Jadx, APKTool, dex2jar |
| Runtime instrumentation | Frida (requires jailbreak or patched IPA) | Frida (requires root or patched APK) |
| Code signing | Mandatory, Apple-controlled | Developer-controlled, sideloading possible |
| Root/jailbreak detection | Jailbreak detection libraries | SafetyNet/Play Integrity API + custom checks |
| IPC mechanism | URL schemes, Universal Links | Intents, Content Providers, Broadcast Receivers |
| Network interception | Bypass ATS + install CA cert | Install CA cert (user or system) |
The key takeaway: even when both apps share the same backend, the client-side attack surface is platform-specific. iOS and Android store data differently, enforce network security differently, and expose different IPC mechanisms. Test each platform with platform-appropriate tools and techniques.
Mobile security testing approaches
Mobile security testing combines multiple methods. No single approach covers the full attack surface.
Static analysis
Static analysis examines the application binary without running it. For Android, tools decompile the APK to recover Java source code, parse the AndroidManifest.xml for misconfigurations, and search for hardcoded secrets, insecure API calls, and weak cryptographic patterns. For iOS, the IPA is extracted and the Mach-O binary is analyzed for similar issues.
Automated static analysis with MobSF or NowSecure scans for common vulnerability patterns in minutes. It catches hardcoded API keys, insecure storage calls, debug flags left enabled, exported components without proper permissions, and use of deprecated cryptographic functions. Static analysis is fast and scalable, making it ideal for CI/CD integration.
The limitation is false positives and missed context. A static scanner may flag a SharedPreferences write as insecure without knowing whether the data is sensitive. It cannot evaluate runtime behavior like certificate pinning enforcement or biometric authentication flows.
Dynamic analysis
Dynamic analysis runs the app on a device or emulator and observes its behavior. This includes monitoring file system changes (what does the app write to disk?), network traffic (what APIs does it call, and is TLS enforced?), and runtime behavior (does jailbreak detection work? can SSL pinning be bypassed?).
Frida is the standard tool for runtime instrumentation. It injects JavaScript into a running process, letting you hook functions, modify return values, bypass security checks, and trace execution flow. Objection builds on Frida with pre-built commands for common mobile testing tasks.
Dynamic testing catches issues that static analysis misses: runtime certificate pinning bypass, insecure data written to disk during actual usage, authentication flows that can be manipulated, and responses to root/jailbreak detection.
Network analysis
Mobile apps communicate with backend APIs over HTTP/HTTPS. Intercepting this traffic with Burp Suite or mitmproxy reveals API endpoints, request/response formats, authentication tokens, and potential server-side vulnerabilities.
On Android, you configure the device to route traffic through your proxy and install a custom CA certificate. On iOS, the same approach works, but ATS may need to be relaxed for interception to succeed. Apps with certificate pinning require additional bypass steps using Frida or Objection before traffic becomes visible.
Network analysis is where mobile testing and web API testing overlap. Once you can see the API traffic, standard web testing techniques apply: testing for broken authentication, authorization bypass, injection, and information disclosure.
Manual pentesting
Automated tools cover the known vulnerability patterns. Manual testing finds what scanners miss: business logic flaws in payment flows, race conditions in multi-step authentication, improper session handling after logout, and authorization bypass between user accounts.
Manual mobile pentesting follows the MASTG test cases and adds creative attack scenarios specific to the application. A banking app needs testing around transaction manipulation. A health app needs testing around data access controls between patient accounts. These application-specific tests require a human tester who understands both the platform and the business domain.
Mobile security tools
The mobile security tool landscape splits into automated scanners for broad coverage and manual tools for deep analysis.
Automated scanning
- NowSecure is the commercial market leader. It provides automated static and dynamic analysis for iOS and Android, integrates into CI/CD pipelines, and maps findings to MASVS and OWASP Mobile Top 10. NowSecure Platform includes continuous monitoring for apps in production.
- MobSF (Mobile Security Framework) is the strongest open-source option with over 20,000 GitHub stars. It handles static analysis, dynamic analysis on emulators, and generates compliance reports. MobSF runs locally and provides a REST API for automation.
- Zimperium combines app scanning (zScan) with on-device threat detection (zIPS). It is popular in enterprise mobility programs that need both pre-release testing and production runtime protection.
- Guardsquare focuses on the protection side: code obfuscation (DexGuard for Android, iXGuard for iOS) and runtime application self-protection (ThreatCast for monitoring).
Manual testing tools
- Frida is the runtime instrumentation framework that most mobile pentesters rely on. It hooks into running iOS and Android processes, letting you bypass security controls, trace function calls, and modify app behavior.
- Objection wraps Frida with a command-line interface and pre-built scripts. Dump the Keychain, bypass SSL pinning, disable root detection, and explore the file system without writing custom Frida scripts.
- Jadx decompiles Android APKs to readable Java source code. It is the fastest way to understand what an Android app does.
- Ghidra and Hopper disassemble iOS binaries for reverse engineering. Ghidra is free (from the NSA). Hopper is a paid alternative popular among macOS users.
For the full list of tools with detailed reviews, see our mobile security tools category page. For a primer on how mobile testing tools work, read our What is Mobile Security Testing? guide.
Getting started
Building a mobile security testing practice does not require a large budget or a dedicated mobile security team. Start with free tools and a structured approach, then scale up as your mobile app portfolio grows.
Start with MobSF for automated baseline scanning. Install MobSF locally using Docker. Upload your APK or IPA file and get a security score within minutes. MobSF checks for hardcoded secrets, insecure storage patterns, missing binary protections, and OWASP Mobile Top 10 compliance. Run it against every release before shipping. Add the MobSF REST API to your CI/CD pipeline so scans happen automatically on every build.
Add Frida and Objection for runtime testing. Once you have the static baseline covered, set up a rooted Android emulator or a jailbroken test device. Install Frida and Objection. Practice bypassing SSL pinning, dumping stored credentials, and disabling root detection on your own app. These skills let you validate whether the protections your development team implemented actually work under attack conditions.
Use the MASVS checklist for structured assessments. Download the OWASP MASVS checklist and walk through each requirement for your app. Use MASTG test cases as your step-by-step guide. This turns ad hoc testing into a repeatable, documented assessment that you can track over time.
Intercept network traffic with Burp Suite. Configure your test device to proxy through Burp Suite. Examine every API call your mobile app makes. Test for authentication bypass, authorization issues, and information disclosure on the server side. Mobile API testing follows the same principles as web API testing once you can see the traffic.
Consider NowSecure for CI/CD integration at scale. When your mobile app portfolio grows beyond a handful of apps, or when you need compliance reporting for regulatory requirements, NowSecure provides automated scanning with deeper analysis than MobSF. It runs against real devices in the cloud, supports both iOS and Android, and generates reports mapped to MASVS and industry standards.
The order matters. Automated static analysis catches the low-hanging fruit. Runtime testing validates that security controls work. Network analysis covers the API layer. Manual testing finds the business logic and platform-specific issues that scanners miss. Layer these approaches and you have a mobile security testing program that covers the full attack surface.
Browse Tools by Category
This hub covers 1 application security categories with 9 tools total. Dive into any category to compare tools, read reviews, and find the best fit for your stack.
Scan mobile apps for vulnerabilities and data leaks
Learning Resources
Deepen your understanding with these in-depth guides covering key concepts, tool comparisons, and implementation strategies.
Frequently Asked Questions
What is mobile application security testing (MAST)?
What is OWASP MASVS?
How is mobile security testing different from web app testing?
Do I need to test both iOS and Android separately?
What are the best mobile security testing tools?
Is OWASP MobSF good enough for mobile security testing?

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.
Comments
Powered by Giscus — comments are stored in GitHub Discussions.