Mapping Mobile Security Testing to OWASP MASVS
OWASP MASVS defines mobile verification requirements. OWASP MASTG provides test guidance and platform knowledge. Neither replaces threat modelling, server-side authorization review, or release approval. Useful mapping starts with a protected asset and a user action, then assigns one MASVS control, a reproducible test, an owner, and evidence that another reviewer can inspect.
Do not mark a control passed because a scanner found no issue. A binary can contain no obvious secret yet still leak data through backup, accept a user-added certificate, or authorize an exported activity incorrectly. Conversely, a single control can need Android, iOS, API, and release-pipeline evidence. Record scope and target build before testing: application ID, version code, commit, variant, device or emulator, test account role, endpoint, and test date.
Build a control register
Create a row per in-scope control. MASVS-STORAGE-2 concerns protection of sensitive data at rest; MASVS-NETWORK-1 concerns secure network communication. The row must say what is being protected, not only which framework category appears in a report.
| MASVS control | Test activity | Completed artifact | Owner | Pass acceptance |
|---|---|---|---|---|
| MASVS-STORAGE-1 | Search package, preferences, databases, files, logs, and backups for classified data. | Storage inventory with paths, classification, and screenshots. | Android/iOS lead | No sensitive value persists outside approved protected storage. |
| MASVS-STORAGE-2 | Trace encryption and key lifecycle; test reinstall, backup, restore, and device-lock changes. | Ciphertext sample, key-use trace, restore result, test notes. | Mobile security owner | Data and key access match documented lifecycle. |
| MASVS-CRYPTO-1 | Inspect algorithms, modes, random source, key sizes, and custom crypto. | Code review record and dependency version list. | Application cryptography owner | No weak, improvised, or undocumented cryptographic construction. |
| MASVS-AUTH-2 | Exercise local authentication before sensitive display or action, including cancel and background paths. | Screen recording, test cases, and state-transition results. | Product security owner | Protected action cannot complete without required reauthentication. |
| MASVS-NETWORK-1 | Intercept and alter traffic, test HTTP, expired certificates, hostname mismatch, and user CA behavior. | Proxy capture, APK config extract, device/version matrix. | Android networking owner | Release traffic uses intended TLS validation; no unapproved cleartext path works. |
| MASVS-NETWORK-2 | Review pinning only where risk model requires it; simulate primary certificate rotation. | Pin inventory, rotation exercise, expiry review. | Service owner | Pin policy has tested backup and recovery plan, or documented decision not to pin. |
| MASVS-PLATFORM-1 | Enumerate exported components, intents, deep links, and WebView bridges; attempt untrusted invocation. | Manifest inventory and invocation results. | Android platform owner | Sensitive components reject untrusted callers and validate input. |
| MASVS-CODE-2 | Review dependencies, target SDK, debug flags, and security-relevant build variants. | SBOM or dependency report, release manifest, CI record. | Build owner | Release artifact matches approved build settings and dependency policy. |
Evidence needs a location, checksum or immutable build identifier, collector, collection date, and result. Screenshots alone are weak evidence when they cannot establish build identity or test input. Preserve command output, decompiled manifest excerpts, intercepted request metadata with secrets removed, and code references. Keep user data out of test artifacts.
Run tests in dependency order
Start with architecture: identify account tokens, locally cached records, signing keys, deep-link actions, APIs, third-party SDKs, and data crossing trust boundaries. Then choose a MASVS profile and controls relevant to those assets. Test static configuration before runtime behavior: compare source manifest and resources with installed release APK because build flavors can change effective policy.
For storage, populate realistic but non-production test markers, then search application sandbox, external locations, backups where permitted, logs, screenshots, and notifications. For network, use a controlled proxy and test a release-signed build on supported Android versions. Failure to intercept traffic is not automatic success: confirm whether certificate validation, pinning, proxy setup, or device trust caused result.
For platform interaction, invoke each exported surface with malformed and unauthorized inputs. For authentication, test process restart, task switching, expired session, biometric cancellation, and server authorization after local UI gate. Server must still authorize operation; local checks are not authorization proof.
Decision, exception, remediation
Result is pass only when stated acceptance is met and completed artifact exists. Result is fail when test demonstrates violation. Result is not verified when evidence or access is missing; do not convert it into pass. An exception needs control ID, business rationale, affected versions and data, compensating controls, accountable owner, expiry date, and explicit approval. “Legacy” without an expiry is not an exception.
Remediation begins with smallest safe change: remove unnecessary data, narrow component exposure, enable intended platform control, or fix server authorization. Owner attaches changed commit, rebuilt artifact ID, regression test result, and retest evidence. Close only when same test passes on affected release candidate. MASVS mapping is a verification aid, not certification or compliance claim. Mobile application testing can assess agreed application and backend scope.
Worked mapping and closure
Map a concrete release feature, not a policy statement, to testable evidence. For biometric unlock, state asset protected, threat boundary, platform API used, fallback behavior, and server consequence. Evidence may include manifest extract, source review location, device test, and backend authorization trace. A mapping row is weak if it says “MASVS compliant” without test identifier, result, build number, and limitation.
Run a negative case: disable device lock, enroll a different biometric, clear application data, then attempt protected action. Expected behavior depends on product design, but evidence must show no stale token or local secret grants access beyond defined session policy. Platform version variation is an edge case; record API level and manufacturer behavior rather than assuming one device proves every release target.
Close each mapped requirement with scope, artifact hash, tester, date, pass/fail result, exception rationale, owner, and retest trigger. MASVS is a verification vocabulary, not certification or guarantee. Reopen rows after authentication redesign, storage migration, network client replacement, or release signing change.
Produce reproducible control evidence
For each row, write exact precondition, tool version, command or UI action, expected response, actual response, and evidence location. Example platform test: install release APK, invoke exported activity from separate UID, capture adb shell am result and backend audit event. Expected result is denial before sensitive action. If app opens screen, distinguish harmless routing from object access by testing foreign identifier after sign-in. Attach device API level because platform behavior changes across releases.
A useful quarterly sample selects one control from each applicable category: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE, and PRIVACY. “Not applicable” needs architecture reason and reviewer, not blank cell. When MASTG procedure cannot run because test account or device is absent, mark not verified and assign access owner. This keeps control register honest during release decision.