Mobile App Security Assessment Template (OWASP MASVS 2.1, MASTG, MASWE)

Mobile App Security Assessment: [App name, platform and version]

Security and privacy assessment record for one Android and/or iOS app release: scope and app profile, choice of MAS testing profile, method and evidence, data flow, assessment of all 24 controls of the OWASP Mobile Application Security Verification Standard (MASVS) v2.1.0 across its eight categories, with weaknesses from the OWASP Mobile Application Security Weakness Enumeration (MASWE) v1.0.0 (August 2026) and atomic tests from the OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0 (June 2026), a scored findings register, summary, remediation, retest and sign-off. Versions as checked in October 2026. The structure, questions and examples are original. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Scope and app profile
2. MAS profile selection
3. Method, evidence and rating
4. Data flow and attack surface
5. Assessment by MASVS category
6. Control results matrix
7. Findings register
8. Summary and release decision
9. Remediation plan and retest
10. Sign-off and next assessment
11. Glossary and references

1. Scope and app profile

In scope: [both release builds, local storage, network traffic to first-party and third-party hosts, IPC surfaces, WebViews, authentication flows, privacy declarations].

Out of scope (with reason): [backend API server-side testing (separate API review), payment provider SDK internals (covered by provider attestation), denial of service].

Test devices: [Pixel test device with Android version n, rooted for dynamic testing; iPhone with iOS version n, jailbroken test device; non-rooted devices for behaviour checks].

2. MAS profile selection

In MASWE v1.0.0, every weakness carries one or more of the profile tags L1, L2, R and P. Example scope: 78 weaknesses in the catalogue, of which 15 are tagged R only (MASWE-0051 to MASWE-0065) and are out of scope because MAS-R is not selected.

3. Method, evidence and rating

Rating. Score each finding as likelihood (1 to 5) x impact (1 to 5). 20 to 25 Critical, 10 to 16 High, 5 to 9 Medium, 1 to 4 Low. Likelihood must reflect the attacker position the weakness needs (another app on the device, physical access to an unlocked device, network position, rooted device), because many mobile weaknesses need a privileged position.

ID translation rule. MASTG v2.0.0 test files reference MASWE beta numbers. Example: MASTG-TEST-0287 (runtime storage of unencrypted data via the SharedPreferences API) carries beta MASWE-0006, which maps to v1.0.0 MASWE-0001 (sensitive data stored unencrypted in private storage). Record the v1.0.0 ID in this document.

4. Data flow and attack surface

5. Assessment by MASVS category

5.1 MASVS-STORAGE

Controls: STORAGE-1 (sensitive data is stored securely) and STORAGE-2 (sensitive data does not leak).

Questions:

• Where does the app write sensitive data (preferences, databases, files, caches, WebView storage, shared containers), and is it encrypted with a key in the platform keystore?
• Does sensitive data appear in logs, backups, keyboard caches or shared storage?
• Are secrets such as API keys or encryption keys hardcoded in the package?

Relevant MASWE v1.0.0: MASWE-0001 to MASWE-0006. Example MASTG tests: Android MASTG-TEST-0287, MASTG-TEST-0203, MASTG-TEST-0262; iOS MASTG-TEST-0299, MASTG-TEST-0296, MASTG-TEST-0215.

5.2 MASVS-CRYPTO

Controls: CRYPTO-1 (current strong cryptography used correctly) and CRYPTO-2 (key management follows good practice).

Questions:

• Which algorithms, modes and key sizes does the app use, and are any broken or deprecated?
• Are keys generated in or protected by the platform keystore, with access restricted to the purpose?
• Is randomness for security purposes taken from a secure source?

Relevant MASWE v1.0.0: MASWE-0007 to MASWE-0017. Example MASTG tests: Android MASTG-TEST-0221, MASTG-TEST-0204, MASTG-TEST-0212; iOS MASTG-TEST-0210, MASTG-TEST-0311, MASTG-TEST-0213.

5.3 MASVS-AUTH

Controls: AUTH-1 (secure authentication and authorization protocols), AUTH-2 (local authentication done securely) and AUTH-3 (sensitive operations need additional authentication).

Questions:

• Does the app rely on the backend for authentication and authorization decisions, using a standard protocol such as OAuth 2.0 with PKCE?
• Is biometric unlock bound to a keystore key (event-bound), and is the key invalidated when a new biometric is enrolled?
• Do sensitive actions (points transfer, profile change) require step-up authentication without a weak fallback?

Relevant MASWE v1.0.0: MASWE-0018 to MASWE-0025. Example MASTG tests: Android MASTG-TEST-0326, MASTG-TEST-0327, MASTG-TEST-0328; iOS MASTG-TEST-0266, MASTG-TEST-0268, MASTG-TEST-0270.

5.4 MASVS-NETWORK

Controls: NETWORK-1 (all traffic secured with current practice) and NETWORK-2 (identity pinning for endpoints the developer controls).

Questions:

• Is any cleartext traffic allowed by configuration (Android network security configuration, iOS App Transport Security exceptions) or used at run time?
• Is server certificate and hostname validation ever weakened in code or WebViews?
• For L2: are first-party endpoints pinned, and do pins have a rotation plan?

Relevant MASWE v1.0.0: MASWE-0026 to MASWE-0028. Example MASTG tests: Android MASTG-TEST-0235, MASTG-TEST-0283, MASTG-TEST-0242; iOS MASTG-TEST-0322, MASTG-TEST-0396, MASTG-TEST-0385.

5.5 MASVS-PLATFORM

Controls: PLATFORM-1 (IPC used securely), PLATFORM-2 (WebViews used securely) and PLATFORM-3 (user interface used securely).

Questions:

• Which components are exported (activities, services, receivers, content providers, URL schemes, universal and app links), and does each check the caller and validate input?
• Do WebViews load only trusted content, and is any native bridge exposed to untrusted pages?
• Is sensitive data hidden in screenshots, app switcher previews, notifications, text fields and the clipboard?

Relevant MASWE v1.0.0: MASWE-0029 to MASWE-0040. Example MASTG tests: Android MASTG-TEST-0364, MASTG-TEST-0393, MASTG-TEST-0252, MASTG-TEST-0289; iOS MASTG-TEST-0370, MASTG-TEST-0376, MASTG-TEST-0290, MASTG-TEST-0276.

5.6 MASVS-CODE

Controls: CODE-1 (up-to-date platform version required), CODE-2 (update enforcement exists), CODE-3 (no components with known vulnerabilities) and CODE-4 (untrusted input validated and sanitised).

Questions:

• Does the app target the latest platform version and refuse to run on unsupported OS versions where needed?
• Can the backend force an update when a vulnerable version is in the field?
• Does the SBOM show components with known vulnerabilities, and are compiler protections enabled for native code?
• Is data from deep links, intents, files and the network validated before use, including deserialisation and SQL?

Relevant MASWE v1.0.0: MASWE-0041 to MASWE-0050. Example MASTG tests: Android MASTG-TEST-0245, MASTG-TEST-0392, MASTG-TEST-0274, MASTG-TEST-0339; iOS MASTG-TEST-0383, MASTG-TEST-0275, MASTG-TEST-0386.

5.7 MASVS-RESILIENCE

Controls: RESILIENCE-1 (platform integrity checked), RESILIENCE-2 (anti-tampering), RESILIENCE-3 (anti-static analysis) and RESILIENCE-4 (anti-dynamic analysis).

Questions (MAS-R only):

• Does the app detect rooted or jailbroken devices, emulators and hooking frameworks, and what does it do on detection?
• Is the app signed with a current scheme, and are code and resources checked for integrity?
• Are security-relevant code paths obfuscated and debug artefacts removed?

Relevant MASWE v1.0.0: MASWE-0051 to MASWE-0065. Example MASTG tests: Android MASTG-TEST-0224, MASTG-TEST-0226, MASTG-TEST-0368; iOS MASTG-TEST-0220, MASTG-TEST-0261, MASTG-TEST-0391. Note that some debug-related weaknesses (for example MASWE-0063, debug mechanisms not disabled) are tagged R in MASWE but still worth checking in every release build.

5.8 MASVS-PRIVACY

Controls: PRIVACY-1 (minimal access to sensitive data and resources), PRIVACY-2 (user not identifiable without need), PRIVACY-3 (transparent about collection and use) and PRIVACY-4 (user control over their data).

Questions (MAS-P):

• Are permissions minimal, requested in context with a rationale, and reset or released when unused?
• Do identifiers used for analytics allow tracking across apps or reinstalls?
• Do the store data declarations, the privacy policy and the iOS privacy manifest match what the app and its SDKs actually collect and send?
• Can users see, export and delete their data and withdraw consent from inside the app?

Relevant MASWE v1.0.0: MASWE-0066 to MASWE-0078. Example MASTG tests: Android MASTG-TEST-0255, MASTG-TEST-0206, MASTG-TEST-0318; iOS MASTG-TEST-0360, MASTG-TEST-0281.

Privacy findings may also have legal effects (for example under the EU and UK GDPR or US state privacy laws). This record documents technical observations; it is not legal advice, so route privacy findings to your privacy or legal team.

6. Control results matrix

Example totals: 24 controls, 20 in scope, 9 Pass, 11 Fail, 4 not applicable. Pass rate for in-scope controls: 9 of 20 (45%).

The profile column is a planning aid derived from the MASWE profile tags of each control's weaknesses; confirm it against the MAS profile pages for your version.

7. Findings register

Detail for each finding (repeat the block):

8. Summary and release decision

Example summary: no Critical findings. Four High findings (MOB-001, MOB-005, MOB-006, MOB-009) allow token theft or unwanted account actions from another app, a WebView page or a copied package, so they block store release of 3.8.0. The six Medium findings are scheduled within 90 days, MOB-010 for the next release.

Findings accepted without a fix need a time-limited security exception through the security exception request process.

9. Remediation plan and retest

Preventive actions:

• Example: Add MASTG static tests that have SAST rules to the mobile CI pipeline.
• Example: Add the MASVS control list to the mobile design review checklist.
• Example: Review every new SDK against PRIVACY-1 to PRIVACY-3 before adding it.

10. Sign-off and next assessment

11. Glossary and references

Standard and licence note

Based on the OWASP Mobile Application Security (MAS) project: MASVS v2.1.0, MASWE v1.0.0 and MASTG v2.0.0, published by the OWASP Foundation under CC BY-SA 4.0. Control IDs, weakness IDs, test IDs and profile names are cited for mapping only; the control summaries, questions, structure and examples are original and no OWASP control, weakness or test text is reproduced, so no ShareAlike obligation arises from this template. If you paste OWASP text into your copy, that adapted material is under CC BY-SA 4.0, must credit OWASP and must be shared alike. Check the current MAS releases before relying on the mapping, because MASWE IDs were renumbered in v1.0.0 and MASTG test references may lag behind. Template licence: MIT.