Mobile App Security Testing: Static vs Dynamic Checks and OWASP MASVS

Mobile app security testing is the practice of checking whether an Android or iOS app protects its users, its data and the backend it calls, using static analysis of the code or compiled package and dynamic analysis of the app while it runs. Defining it is easy; the friction for a QA lead comes from the fact that QA owns the evidence behind a release decision, while security testing tends to live with a separate team or an outside vendor. This guide maps static and dynamic checks to OWASP MASVS, shows which kind of tool covers each one, and places every check at a specific point in your release so security findings sit beside your functional results instead of arriving after launch.

What is mobile app security testing?

The OWASP Mobile Application Security Testing Guide treats the phrase as a catchall: any evaluation of a mobile app's security through static and dynamic analysis. It also notes that a mobile test usually sits inside a wider assessment that covers the server-side APIs the app depends on, because a locked-down client talking to a careless endpoint still leaks data.

Vendor pages and analyst reports shorten the category to MAST, and Gartner applies that label to tools that combine static analysis, behavioural observation and dynamic testing of mobile binaries.

Mobile needs its own approach for one plain reason. Your compiled APK or IPA ships to phones you do not control. Anyone can download it, unpack it, read its resources, attach a debugger and watch the traffic it sends. A web server hides its code from visitors; a mobile release hands a copy of its code to every one of them.

What do OWASP MASVS and MASTG cover?

OWASP runs the Mobile Application Security (MAS) project, and its pieces answer different questions. Think of the Mobile Application Security Verification Standard (MASVS) as the bar your build must clear, written as controls rather than test steps. The current version, v2.1.0, groups 24 controls into eight categories: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY. The privacy category arrived with that release.

Its companion, the Mobile Application Security Testing Guide (MASTG), supplies the procedures a tester follows to prove each of those controls on an Android or iOS build. Its v2.0.0 release in mid 2026 rebuilt the tests so each one links to an entry in the Mobile Application Security Weakness Enumeration (MASWE), which in turn points back to a MASVS control. Every test is tagged with a platform and a type such as static, dynamic or manual, which makes it easier to decide where a test belongs in your pipeline.

Depth comes from the MAS Testing Profiles. MAS-L1 covers essential security, MAS-L2 adds advanced controls for apps that move money or hold health records, MAS-R targets tamper resistance, and MAS-P sets a privacy baseline. Many consumer apps begin with L1 plus P and add L2 for sensitive flows.

Two housekeeping notes. OWASP stopped publishing the MAS checklist spreadsheet as an official artifact with MASTG v2, so track coverage on the MAS website or in your own tracker. And the OWASP Mobile Top 10 (2024 edition) is an awareness list of common risks, not a test standard; our guide to mobile app security reports walks through that list.

Table 1: MASVS categories mapped to static and dynamic checks

MASVS category	What it protects	Static check examples	Dynamic check examples	Usual owner
MASVS-STORAGE	Sensitive data kept on the device	Backup flags enabled in the manifest, files created with world-readable modes	Tokens or personal data actually present in shared preferences, plain databases or logs after a session	Mobile engineer, security engineer
MASVS-CRYPTO	Keys and cryptographic operations	Hardcoded keys, deprecated algorithms such as MD5 or ECB mode in calls	Key material visible in memory or traffic during a login or payment run	Security engineer
MASVS-AUTH	Login, sessions and step-up checks	Biometric prompts that never bind to a stored key, auth logic implemented only on the client	Sessions that survive logout, tokens accepted after expiry, step-up skipped on a payout screen	Security engineer, QA
MASVS-NETWORK	Data moving between app and servers	Cleartext permitted in the Android network security config, broad App Transport Security exceptions on iOS	Requests leaving over plain HTTP, the app accepting a forged certificate	Mobile engineer, QA
MASVS-PLATFORM	Exported components, deep links, WebViews	Exported activities without permission checks, JavaScript bridges enabled in WebViews	Deep links that open protected screens, intents from another app that trigger actions	Mobile engineer, security engineer
MASVS-CODE	Dependencies, input handling, update hygiene	Outdated bundled libraries with known issues, debuggable flag left on in a release build	Malformed input that crashes the app, forced-update logic that a user can bypass	Mobile engineer, QA
MASVS-RESILIENCE	Resistance to tampering and reverse engineering	Missing obfuscation, absent integrity or root and jailbreak checks	App continuing to run under a hooking framework or after a repackaged build is installed	Security engineer
MASVS-PRIVACY	Data minimisation and user transparency	SDKs and permissions declared beyond what features need	Data actually collected at runtime matching the store privacy labels, consent screens honoured	Product owner, security engineer

Static vs dynamic mobile security testing: what each finds

Static analysis

Static analysis reads source code, bytecode or the compiled package without launching it. It is good at configuration and code-level evidence: debuggable or backup flags in the manifest, exported components, the permissions an app requests, signing certificate details, API keys pasted into resources, weak hashing calls, cleartext exceptions in network settings and bundled libraries with published vulnerabilities. A scan finishes quickly enough to run on every build. The cost is noise. Some findings are false positives or acceptable trade-offs, so someone has to triage them against agreed rules.

Dynamic analysis

Dynamic analysis installs the app on a device or emulator, signs in with test accounts and watches what really happens. It answers questions a file scan cannot: which values land in local storage after checkout, what each request carries over the wire, whether a session token still works after logout, whether a deep link from another app can reach a protected screen, and how the build behaves when someone hooks it. It needs a testable build, seeded accounts and usually a specialist who knows the tooling.

Penetration testing

A penetration test is a person thinking like an attacker for a scoped period. Testers chain small weaknesses, abuse business rules and probe server logic that automated scanners do not model. It is slower and costs more, so teams reserve it for high-risk changes.

Here is a fictional example. A wallet app release adds a payout screen. The static scan flags a debug flag left on and a cleartext exception for a staging domain in the network configuration. Dynamic testing on a test device finds the payout token written to unencrypted local storage. Because money moves through that screen, the team books a penetration test to probe payout limits and replayed requests.

Which mobile app security testing tools fit each check?

Choose tools by the check they perform rather than by brand. Each type sees a different slice of the app.

Table 2: Mobile app security testing tool types

Tool type	What it tests	When it runs	What it misses	Examples
SAST (static application security testing)	Source code in the repository	Every commit or pull request	Anything added at build time, runtime behaviour, backend flaws	Code scanners inside your Git platform or IDE
MAST platform	Compiled APK or IPA, statically and on devices at runtime	Release candidates, sometimes nightly	Business logic abuse, flaws that need human chaining	NowSecure, MobSF, Ostorlab, Appknox
DAST and API security testing	Backend endpoints the app calls	Staging deploys and release candidates	Client-side storage, binary configuration	API scanners pointed at staging
Penetration testing	Whole system through an attacker's eyes	High-risk releases, annual reviews	Day-to-day regressions between engagements	Internal red team or external testing firm
QA-integrated static scan	Uploaded app version: manifest, certificate, code and network settings	When a version is uploaded for testing	All dynamic and runtime behaviour	QApilot Security Analysis

Dynamic application security testing (DAST) is written for web and API targets, so it does not see what the client stores on a handset. Interactive testing (IAST) instruments a running server and appears less often in mobile programmes.

People searching for mobile app security testing services usually want to hand the work to someone else. A managed service or testing firm changes who runs the tests and who interprets the results. It does not change which checks matter, so hold any provider to the same MASVS categories and profile you would use in house. For a side-by-side look at what vendor reports contain, see the reporting guide linked earlier.

How do you make security a release-readiness gate?

A gate works when three things are agreed before the first scan: which check runs at each stage, which findings stop a release, and who decides on exceptions.

1. Every build or pull request. Run a static scan. Agree a blocking rule up front, for example that any new critical finding fails the build while existing accepted items are tracked.
2. Release candidate. Run a fuller static pass plus dynamic testing on a device build. NowSecure's own CI guidance recommends this split: static analysis on commits and a full static and dynamic assessment on release tags.
3. High-risk release. Schedule a scoped penetration test when the change touches payments, identity or health data.

Then put the security result in the same go/no-go review as your functional regression, performance and accessibility results. If you already run a mobile app testing checklist by release stage, security becomes one row with an owner, not a separate meeting. A security engineer owns triage and risk acceptance. QA keeps the evidence: the report for each build version and a list of accepted risks, each with an expiry date so nothing stays waived forever. Our guide on security report findings QA teams skip covers triage habits worth borrowing.

To wire the stages into your build system, see how to add security checks to your mobile CI/CD pipeline.

Can mobile app security testing be automated?

Partly. Repeatable work automates well: static scans on every build, baseline dynamic scans where your MAST platform supports them, and regression checks that confirm a fixed issue stays fixed. Judgement does not. Exploit chains, business logic abuse and risk acceptance need a person. So does privacy. OWASP's v2.1.0 release notes explain that several MASVS-PRIVACY controls depend on manual review, such as comparing what an app collects with what its store listing discloses. Automate the evidence collection, and keep the decisions with people who can explain them.

Where QApilot fits

QApilot is a mobile testing platform, not a security scanner replacement, and its security feature is deliberately narrow. When you upload an app version, you can tick a Security Analysis option. QApilot then runs static analysis on that version and produces one security report, with findings grouped into Manifest, Certificate, Code and Network Security areas. The report lives in the same Reports area as functional execution and accessibility reports, so QA sees security findings beside test evidence for the same build.

The QApilot documentation is explicit that this supplements test execution reporting and does not replace a complete security assessment. In practice, pair it with a dedicated MAST tool for dynamic testing, a penetration tester for high-risk releases and your device cloud for execution. Separately, test plans can blur personal data such as phone numbers or card numbers in captured screenshots, which keeps test artifacts cleaner. You can see how this fits the wider QApilot release readiness workflow.

Mobile app security testing FAQ

What is mobile app security testing?

It is the process of confirming that an Android or iOS app guards its data, its users and the services behind it. Testers combine static review of the code or compiled package with dynamic observation of the running app, judge results against OWASP MASVS, and follow MASTG test procedures. Sensitive apps add backend API testing and a human penetration test.

What is the difference between static and dynamic mobile app security testing?

Static testing inspects the source or the APK or IPA file without running it, catching things like debug flags, embedded secrets, weak cipher choices and permissive network settings. Dynamic testing launches the app on a device and records what it stores, transmits and accepts during real sessions. Run static scans on each build and dynamic tests on release candidates.

Which OWASP standard should I use for mobile app security testing?

Use MASVS v2.1.0, with its eight categories and 24 controls, as your list of requirements, and the MASTG as your testing method. Pick a MAS Testing Profile, such as L1 for most apps or L2 for payment and health apps, to set depth. Treat the OWASP Mobile Top 10 as background reading on common risks rather than a test plan.

Start with one gate

You do not need a full programme on day one. Turn on a static scan for your next build, agree in writing which findings block a release, and book dynamic testing for the next release candidate. Once security results sit in the same review as your functional and accessibility evidence, every later step is easier to justify.