# 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*.

<!--
Guidance: How to use this template
- Use one record per app release and platform pair you assess (for
  example Android 3.8.0 and iOS 3.8.0 built from the same code base).
- Pick the MAS profile in section 2 before testing. The profile decides
  which weaknesses are in scope; resilience (MAS-R) and privacy (MAS-P)
  are separate choices, not "extra credit".
- Work category by category in section 5. Every MASVS control ends with a
  result: Pass, Fail (with finding IDs) or Not applicable with a reason.
- Cite three IDs per finding: the MASVS control (what is required), the
  MASWE weakness (what is wrong) and the MASTG test (how it was shown).
- Pitfall: MASWE v1.0.0 (17 August 2026) renumbered every weakness, while
  the MASTG v2.0.0 test files (30 June 2026) still carry the older beta
  MASWE numbers. Always translate test references to the v1.0.0 IDs with
  the `maswe-beta` mapping published with MASWE v1.0.0, and record the
  version you used.
- Related templates: [Mobile architecture](../architecture/mobile-architecture.md),
  [Mobile backend design](../architecture/mobile-backend-design.md),
  [API security review](../security/api-security-review.md),
  [Threat model](../security/threat-model.md),
  [Privacy threat model](../security/privacy-threat-model.md),
  [Penetration test report](../security/pentest-report.md) and
  [Secure coding standard](../security/secure-coding-standard.md).
-->

## Document control

<!-- Guidance: Record exact build identifiers: a mobile finding without the build number and signing certificate cannot be retested reliably. Name the owner who accepts residual risk before store release. -->

| Field | Value |
|---|---|
| Document ID | [MASA-2026-004] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner (app product owner) | [@mobile-owner] |
| Assessor(s) | [@mobile-security-tester], [@second-assessor] |
| Approvers | [@engineering-lead], [@security-lead], [@privacy-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential: contains unremediated findings] |
| App and builds | [Android `com.example.app` 3.8.0 (380), iOS 3.8.0 (2026.10.1)] |
| MAS profile | [MAS-L2 + MAS-P] |
| Baselines | OWASP MASVS v2.1.0; MASWE v1.0.0; MASTG v2.0.0 |
| Assessment window | YYYY-MM-DD to YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Lead assessor | [@name] | [Submitted] | YYYY-MM-DD |
| App product owner | [@name] | [Accepted / Accepted with conditions / Rejected] | YYYY-MM-DD |
| Security lead | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Privacy lead (MAS-P) | [@name] | [Approved / Changes requested] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Scope, profile and builds recorded |
| 0.9 | YYYY-MM-DD | [@name] | *Example:* Testing complete, 11 findings recorded |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Owner decision and remediation dates agreed |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Retest of MOB-001, MOB-005 and MOB-009 on Android build 381 and MOB-006 on iOS build 2026.10.2 |

## Contents

1. [Scope and app profile](#1-scope-and-app-profile)
2. [MAS profile selection](#2-mas-profile-selection)
3. [Method, evidence and rating](#3-method-evidence-and-rating)
4. [Data flow and attack surface](#4-data-flow-and-attack-surface)
5. [Assessment by MASVS category](#5-assessment-by-masvs-category)
6. [Control results matrix](#6-control-results-matrix)
7. [Findings register](#7-findings-register)
8. [Summary and release decision](#8-summary-and-release-decision)
9. [Remediation plan and retest](#9-remediation-plan-and-retest)
10. [Sign-off and next assessment](#10-sign-off-and-next-assessment)
11. [Glossary and references](#11-glossary-and-references)

## 1. Scope and app profile

<!-- Guidance: Describe the app so an assessor who has never seen it knows what to protect. Questions: What sensitive data does the app hold or show? Which backend APIs does it call? Which third-party SDKs are embedded? Which platform features (WebViews, deep links, widgets, extensions, biometrics) does it use? Pitfall: assessing only the app binary while the most serious issues sit in the backend API; link the API review instead of duplicating it. -->

| Item | Value |
|---|---|
| App purpose | *Example:* Tallowmere Rewards: loyalty points, stored payment card reference, points transfer between members |
| Platforms and minimum OS | *Example:* Android minimum API level 28, target API level [current]; iOS minimum 16 |
| Build type assessed | [Release build signed for store, plus debug build for dynamic testing] |
| Framework | [Native Kotlin and Swift / React Native / Flutter / .NET MAUI / Kotlin Multiplatform] |
| Sensitive data | *Example:* Session tokens, member profile, partial card number, location (for store finder) |
| Backend APIs | *Example:* `api.[example].com/v2` (reviewed in [APISR-2026-001]) |
| Third-party SDKs | *Example:* Crash reporting, push notifications, maps, analytics (list with versions in the SBOM) |
| Platform features | *Example:* WebView for offers, app links, biometric unlock, push notifications, home-screen widget |
| Distribution | [Google Play, Apple App Store, enterprise MDM] |

**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

<!-- Guidance: The OWASP MAS project defines testing profiles that decide which MASWE weaknesses apply. Choose based on the data and the threat, record the reason and get the owner to agree before testing. Pitfall: requiring MAS-R (anti-tampering) for every app; it adds cost and only makes sense when reverse engineering or tampering is a real business threat. -->

| Profile | Use when (own summary) | Selected | Reason |
|---|---|---|---|
| MAS-L1 Essential Security | Baseline for every app: secure storage, network, platform use and code hygiene | Yes (always) | Minimum |
| MAS-L2 Advanced Security | Apps handling sensitive data or transactions, where defence in depth is expected | *Example:* Yes | Points transfer has monetary value; stored card reference |
| MAS-R Resilient Security | Apps where reverse engineering, tampering or cloning is a business threat (for example DRM, games, payment apps with client-side secrets) | *Example:* No | No client-side logic whose disclosure causes loss; server enforces all limits |
| MAS-P Baseline Privacy | Apps that collect personal data or embed tracking SDKs | *Example:* Yes | Location, profile and analytics SDK |

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

<!-- Guidance: List the techniques and tools you used and how findings are rated. MASTG v2 tests come in pairs: a static test (references to an API in code or configuration) and a runtime test (the API actually used at run time). Record both where possible. -->

| Technique | Purpose | MASTG v2 test style | Used |
|---|---|---|---|
| Static analysis of the package | Configuration, manifest and plist settings, API references, hardcoded data | "References to ..." tests | [Yes / No] |
| Dynamic analysis on device | Runtime behaviour, storage written, IPC, WebView behaviour | "Runtime use of ..." tests | [Yes / No] |
| Network interception | TLS, pinning, cleartext, personal data in traffic | Network traffic tests | [Yes / No] |
| Dependency and SBOM analysis | Known vulnerable components | SBOM tests | [Yes / No] |
| Privacy declaration review | Store data declarations, permission rationale, tracking domains | Privacy tests | [Yes / No] |

```mermaid
flowchart LR
    A["Builds and scope"] --> B["Select MAS profile"]
    B --> C["Static tests"]
    B --> D["Dynamic and network tests"]
    C --> E["Map results to MASVS controls"]
    D --> E
    E --> F["Translate test MASWE IDs to v1.0.0"]
    F --> G["Findings register and rating"]
    G --> H["Owner decision"]
    H --> I["Fix, retest on new build"]
```

**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

<!-- Guidance: Show where sensitive data lives and moves. Each arrow that leaves the app sandbox is an attack surface to test. Keep the names the same as in section 5 and the findings register. -->

```mermaid
flowchart TB
    U["User"] --> UI["App UI"]
    UI --> ST["Private storage and keystore"]
    UI --> WV["Offers WebView"]
    UI --> IPC["Exported components and deep links"]
    UI --> NET["Network client"]
    NET --> API["First-party API"]
    NET --> SDK["Third-party SDK hosts"]
    OA["Other apps on device"] --> IPC
    WV --> WEB["Offer content server"]
    UI --> OS["OS services: backup, clipboard, notifications, screenshots"]
```

| Surface | Sensitive data crossing | Main MASVS controls | Tested |
|---|---|---|---|
| Private storage and keystore | Session token, profile, keys | STORAGE-1, CRYPTO-2 | [Yes] |
| OS services | Card fragment on screen, notifications | STORAGE-2, PLATFORM-3 | [Yes] |
| Exported components and deep links | Account actions | PLATFORM-1, CODE-4 | [Yes] |
| WebView | Session context, JavaScript bridge | PLATFORM-2 | [Yes] |
| Network | All API traffic | NETWORK-1, NETWORK-2 | [Yes] |
| Third-party SDKs | Device and usage data | PRIVACY-1 to PRIVACY-3, CODE-3 | [Yes] |

## 5. Assessment by MASVS category

<!-- Guidance: For each category, answer the questions, list the relevant MASWE weaknesses for your profile and the MASTG tests you ran, then record a result per control in section 6. Control summaries are original one-line paraphrases; read MASVS for the control statements. -->

### 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

<!-- Guidance: One row per MASVS v2.1.0 control (24 in total). The counts below the table must match the rows. Not applicable needs a reason. -->

| Control | Own short summary | Profile in scope | Result | Findings |
|---|---|---|---|---|
| MASVS-STORAGE-1 | Store sensitive data securely | L1, L2 | *Example:* Fail | MOB-001, MOB-009 |
| MASVS-STORAGE-2 | Prevent sensitive data leaks | L1, L2 | *Example:* Fail | MOB-002 |
| MASVS-CRYPTO-1 | Strong, current cryptography | L1, L2 | *Example:* Pass | |
| MASVS-CRYPTO-2 | Sound key management | L1, L2 | *Example:* Fail | MOB-009 |
| MASVS-AUTH-1 | Secure auth protocols | L1, L2 | *Example:* Pass | |
| MASVS-AUTH-2 | Secure local authentication | L2 | *Example:* Fail | MOB-007 |
| MASVS-AUTH-3 | Step-up for sensitive operations | L1, L2 | *Example:* Pass | |
| MASVS-NETWORK-1 | Secure all network traffic | L1, L2 | *Example:* Fail | MOB-003 |
| MASVS-NETWORK-2 | Identity pinning | L2 | *Example:* Fail | MOB-004 |
| MASVS-PLATFORM-1 | Secure IPC | L1, L2 | *Example:* Fail | MOB-005 |
| MASVS-PLATFORM-2 | Secure WebViews | L1, L2 | *Example:* Fail | MOB-006 |
| MASVS-PLATFORM-3 | Secure user interface | L2 | *Example:* Fail | MOB-011 |
| MASVS-CODE-1 | Up-to-date platform | L1, L2 | *Example:* Pass | |
| MASVS-CODE-2 | Update enforcement | L2 | *Example:* Pass | |
| MASVS-CODE-3 | No known vulnerable components | L1, L2 | *Example:* Fail | MOB-008 |
| MASVS-CODE-4 | Validate untrusted input | L1, L2 | *Example:* Pass | |
| MASVS-RESILIENCE-1 | Platform integrity | R | *Example:* N/A (MAS-R not selected) | |
| MASVS-RESILIENCE-2 | Anti-tampering | R | *Example:* N/A (MAS-R not selected) | |
| MASVS-RESILIENCE-3 | Anti-static analysis | R | *Example:* N/A (MAS-R not selected) | |
| MASVS-RESILIENCE-4 | Anti-dynamic analysis | R | *Example:* N/A (MAS-R not selected) | |
| MASVS-PRIVACY-1 | Data and resource minimisation | P | *Example:* Fail | MOB-010 |
| MASVS-PRIVACY-2 | Prevent user identification | P | *Example:* Pass | |
| MASVS-PRIVACY-3 | Transparency | P | *Example:* Pass | |
| MASVS-PRIVACY-4 | User control | P | *Example:* Pass | |

*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

<!-- Guidance: One row per finding and platform. Title states the weakness. Keep tokens, keys and personal data out of the evidence; reference redacted screenshots or logs instead. -->

| ID | Title | Platform | MASVS | MASWE v1.0.0 | MASTG test | L | I | Score | Severity | Owner | Due |
|---|---|---|---|---|---|---|---|---|---|---|---|
| MOB-001 *(Example)* | Session token stored unencrypted in shared preferences | Android | STORAGE-1 | MASWE-0001 | MASTG-TEST-0287 | 3 | 4 | 12 | High | [@android-lead] | YYYY-MM-DD |
| MOB-002 *(Example)* | Member email and points balance written to system log | Android | STORAGE-2 | MASWE-0005 | MASTG-TEST-0203 | 3 | 3 | 9 | Medium | [@android-lead] | YYYY-MM-DD |
| MOB-003 *(Example)* | Cleartext traffic permitted for analytics domain | Android | NETWORK-1 | MASWE-0026 | MASTG-TEST-0235 | 3 | 3 | 9 | Medium | [@android-lead] | YYYY-MM-DD |
| MOB-004 *(Example)* | No pinning for first-party API host | iOS | NETWORK-2 | MASWE-0028 | MASTG-TEST-0385 | 2 | 3 | 6 | Medium | [@ios-lead] | YYYY-MM-DD |
| MOB-005 *(Example)* | Exported activity starts account deletion without caller check | Android | PLATFORM-1 | MASWE-0018 | MASTG-TEST-0364 | 3 | 4 | 12 | High | [@android-lead] | YYYY-MM-DD |
| MOB-006 *(Example)* | Native bridge in offers WebView returns session token to page script | iOS | PLATFORM-2 | MASWE-0033 | MASTG-TEST-0376 | 2 | 5 | 10 | High | [@ios-lead] | YYYY-MM-DD |
| MOB-007 *(Example)* | Points transfer accepts device passcode fallback | iOS | AUTH-2 | MASWE-0021 | MASTG-TEST-0268 | 2 | 3 | 6 | Medium | [@ios-lead] | YYYY-MM-DD |
| MOB-008 *(Example)* | Image library with known vulnerability in SBOM | Android, iOS | CODE-3 | MASWE-0044 | MASTG-TEST-0274, MASTG-TEST-0275 | 2 | 4 | 8 | Medium | [@mobile-platform] | YYYY-MM-DD |
| MOB-009 *(Example)* | Symmetric key for offline cache hardcoded in code | Android | STORAGE-1, CRYPTO-2 | MASWE-0003 | MASTG-TEST-0212 | 3 | 4 | 12 | High | [@android-lead] | YYYY-MM-DD |
| MOB-010 *(Example)* | Background location requested where foreground is enough | Android | PRIVACY-1 | MASWE-0066 | MASTG-TEST-0255 | 2 | 2 | 4 | Low | [@product-owner] | YYYY-MM-DD |
| MOB-011 *(Example)* | Card fragment visible in app switcher snapshot | Android, iOS | PLATFORM-3 | MASWE-0038 | MASTG-TEST-0289, MASTG-TEST-0290 | 2 | 3 | 6 | Medium | [@mobile-platform] | YYYY-MM-DD |

Detail for each finding (repeat the block):

| Field | MOB-006 *(Example)* |
|---|---|
| Description | The offers WebView registers a script message handler that returns the current session token to any page loaded in the WebView. Offer pages can include third-party content. |
| Attacker position | Control over any content loaded in the offers WebView (compromised offer partner or injected script). |
| Reproduction | Load a test offer page that calls the handler; the token is returned to page script (redacted log reference [EV-14]). |
| Impact | Session takeover for the member viewing the offer, including points transfer. |
| Recommendation | Remove the token from the bridge; expose only narrow actions, check the message origin, and load third-party content outside the bridged WebView. |
| References | MASVS-PLATFORM-2; MASWE-0033; MASTG-TEST-0376 (MASTG v2.0.0). The test carries beta MASWE-0069, which the mapping translates to MASWE-0034 (local resources); the weakness actually shown, a bridge exposing the token, is MASWE-0033, so record that ID and note the test's own tag |

## 8. Summary and release decision

<!-- Guidance: Give the owner a one-screen summary with counts that match section 7, then the decision and conditions. -->

| Severity | Count *(Example)* | Share |
|---|---|---|
| Critical | 0 | 0.0% |
| High | 4 | 36.4% |
| Medium | 6 | 54.5% |
| Low | 1 | 9.1% |
| **Total** | **11** | **100%** |

*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.

| Decision | Conditions | Decided by | Date |
|---|---|---|---|
| [Release / Release with conditions / Do not release] | *Example:* Release 3.8.1 after the four High findings are fixed and retested | [@mobile-owner] | YYYY-MM-DD |

Findings accepted without a fix need a time-limited security exception through the [security exception request](../security/security-exception-request.md) process.

## 9. Remediation plan and retest

<!-- Guidance: Retest on the new build number, with the same MASTG tests, and record the build. Add automated checks (static rules, unit tests, CI policy) so the weakness does not return. -->

| ID | Fix | Automated check added | Fixed in build | Retest date | Retest result | Status |
|---|---|---|---|---|---|---|
| MOB-001 *(Example)* | Token in encrypted storage with keystore-backed key | Static rule for plain preference writes of tokens | 3.8.1 (381) | YYYY-MM-DD | Pass | Closed |
| MOB-005 *(Example)* | Activity not exported; deletion requires in-app confirmation and step-up | Manifest lint rule | 3.8.1 (381) | YYYY-MM-DD | Pass | Closed |
| MOB-006 *(Example)* | Bridge removed from offers WebView; origin check on remaining handler | Unit test on handler | 3.8.1 (2026.10.2) | YYYY-MM-DD | Pass | Closed |
| MOB-009 *(Example)* | Key generated in Android Keystore at first run | Secret scanning in CI | 3.8.1 (381) | YYYY-MM-DD | [Pending] | Open |

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

<!-- Guidance: Record closure and plan the next assessment. Mobile apps change often; set triggers as well as a calendar date. -->

| Item | Value |
|---|---|
| All High findings closed or excepted | [Yes / No] |
| Residual risk accepted by | [@mobile-owner], YYYY-MM-DD |
| Next full assessment | YYYY-MM-DD (at least yearly, or each major release) |
| Earlier assessment triggers | New authentication method, new WebView content source, new SDK with data access, new platform major version, MASVS or MASWE release, security incident |
| MAS versions to recheck | MASVS (GitHub releases), MASTG, MASWE |

## 11. Glossary and references

<!-- Guidance: Define terms and record exact versions; MAS documents change often and IDs are only stable from MASWE v1.0.0 onward. -->

| Term | Meaning |
|---|---|
| MASVS | Mobile Application Security Verification Standard: the controls an app should meet |
| MASWE | Mobile Application Security Weakness Enumeration: weaknesses that link MASVS controls to MASTG tests |
| MASTG | Mobile Application Security Testing Guide: techniques, tools and atomic tests |
| MAS profile | Testing profile (L1, L2, R, P) that decides which weaknesses apply |
| IPC | Inter-process communication: intents, content providers, URL schemes, app links and extensions |
| Identity pinning | Accepting only specific certificates or public keys for a host, beyond normal trust validation |
| Event-bound biometrics | Biometric check that unlocks a keystore key, so the result cannot simply be faked in app code |

| Reference | Version (as checked October 2026) | Official page |
|---|---|---|
| OWASP MASVS | v2.1.0 (18 January 2024, latest release) | https://github.com/OWASP/masvs/releases |
| OWASP MASTG | v2.0.0 (30 June 2026) | https://github.com/OWASP/mastg/releases |
| OWASP MASWE | v1.0.0 (17 August 2026) | https://github.com/OWASP/maswe/releases |
| MASWE v1.0.0 announcement | 17 August 2026 | https://mas.owasp.org/news/2026/08/17/maswe-v100-release/ |
| OWASP MAS project site | Living | https://mas.owasp.org/ |

## 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.