V1.0.0 RC

[cpholguera]

This PR applies the v1.0.0-rc remapping: every weakness gets a new, stable ID (and usually a new title), old IDs are consolidated or retired, and several brand new weaknesses are introduced. It also brings all weaknesses up to a single, consistent authoring standard (no placeholders left) and adds a few new metadata fields.

Check the CSV with the mappings from beta to v1.0.0 RC: maswe.csv

Result: 77 weaknesses (was 119), organized as:

Category	Count
MASVS-STORAGE	6
MASVS-CRYPTO	10
MASVS-AUTH	8
MASVS-NETWORK	3
MASVS-PLATFORM	12
MASVS-CODE	11
MASVS-RESILIENCE	17
MASVS-PRIVACY	10

All 77 weaknesses are now status: new — there are no remaining placeholder or draft entries.

1. ID remapping

• 72 weaknesses renamed from their old ID/category to the new one (preserving lineage, e.g. old MASWE-0031 → new MASWE-0019).
• 47 absorbed weaknesses removed each was folded into a new weakness's content;
  their old ID is preserved in that file's mappings.maswe-beta list (see §4).
• 5 brand-new weaknesses created with no predecessor:
  • MASWE-0039 — Sensitive Data Leaked via Accessibility Services
  • MASWE-0074 — Usage of Non-Privacy-Preserving Functionality
  • MASWE-0075 — Malicious Code Included in the App
  • MASWE-0076 — Malware Detection Not Implemented
  • MASWE-0077 — Non-Reproducible Builds

2. Content changes

• Every renamed file got its id/title updated to match the new scheme.

• Editorial merges: where multiple old weaknesses were consolidated into one, the new file's
  prose (Overview / Modes of Introduction / Mitigations) was rewritten to cover the union of the
  original content — not just the primary predecessor. Notable consolidations:

  • MASWE-0011 (Improper Encryption) — absorbs IV misuse, key reuse, and risky padding
  • MASWE-0020 (Lack of Authentication/Authorization on App Components) — absorbs services,
    broadcast receivers, content providers, activities, unauthenticated IPC, and more
  • MASWE-0024 (Lack of Auto-fill Support for Authenticators) — absorbs passwordless auth,
    shared web credentials, and platform auth-API usage
  • MASWE-0047 (Using Non-Standard APIs for Security-Critical Functionality) — absorbs risky
    crypto, non-proven networking APIs, and non-standard auth; broadened to also cover apps that
    fail to leverage secure platform functionality (e.g. custom DNS vs. Private DNS)
  • MASWE-0048 (Unsafe Handling of Untrusted Data) — absorbs the entire "unsafe handling of data
    from X" family (network, backups, external interfaces, local storage, UI, IPC) plus SQLi,
    parsing/escaping, and deserialization
  • MASWE-0054 (Debug Artifacts Not Removed) — absorbs non-production resources, debugging
    symbols, and code that disables security controls; clarified against MASWE-0006 (which
    covers leaked leftovers vs. 0054's debug/resilience artifacts)
  • MASWE-0062 (App Attestation Not Implemented) — repositioned from "Official Store
    Verification" to app-signature/attestation-based integrity checking
  • Several others (0007, 0013, 0021, 0025, 0035, 0038, 0050, 0056, 0058, 0071,
    etc.) — smaller merges, see individual files' mappings.maswe-beta

• Placeholder finalization: every previously status: placeholder weakness (54 of them) has
  been fully written and promoted to status: new, and the temporary draft metadata block
  (draft.description / draft.topics) has been removed. Drafting drew on the related MASTG-TEST
  and MASTG-BEST content to keep the Modes of Introduction and Mitigations grounded in what is
  actually testable and actionable.

• Full standardization: every weakness now follows the authoring standard defined in
  .github/instructions/maswe.instructions.md:

  • The four required sections in a fixed order — ## Overview, ## Modes of Introduction,
    ## Impact, ## Mitigations (previously some pages ordered Impact before Modes of
    Introduction).
  • ## Overview opens with a single-sentence definition in the form " occurs when …".
  • ## Modes of Introduction describes only developer-introduced, testable causes (consequences
    were moved out to ## Impact); each bullet uses a bold short label.
  • ## Mitigations are actionable, imperative bullets with bold short labels.

• New threat and attack model: what an attacker achieves, and how, is no longer written as prose
  in each weakness. It is expressed as structured, ID-referenced frontmatter drawn from two new
  enumerations under .github/instructions/:

  • threats.yaml: the closed set of MAS-THREAT-XXXX outcomes (e.g. MAS-THREAT-0001:
    "Attackers can access sensitive data written to logs."), referenced by the new threat: field.
    77 threats, one per weakness.
  • attacks.yaml: the closed set of MAS-ATTACK-XXXX paths through which a threat is realized
    (e.g. MAS-ATTACK-0001: "Obtaining the app package and reverse engineering it."), referenced
    by the new attacks: [MAS-ATTACK-XXXX, ...] field, IDs in ascending order. 89 attacks, reused
    across weaknesses — an average of two per weakness, and every one of the 89 is used at least
    once.

  Both enumerations are append-only: IDs are never reused or renumbered, so they are stable
  identifiers that MASTG content and external consumers can reference directly.

• Standardized Impact model: with the outcome and attack paths moved to frontmatter, ## Impact
  now contains only the consequences — a flat bulleted list, each opening with a canonical label
  from the new .github/instructions/impact.yaml (Compromise of Sensitive Data, Authentication
  or Authorization Bypass, Bypass of Protection Mechanisms, Execution of Unauthorized Code,
  Financial Loss, Compromise of System Integrity and Business Operations, Violation of User
  Privacy, Loss of User Trust, Legal and Regulatory Non-Compliance) and closing with a
  resulting in clause. Unlike threats and attacks, impact labels are a fixed vocabulary and carry
  no IDs. Equivalent consequences share identical wording across weaknesses.

• Cross-references between related weaknesses added/fixed using the @MASWE-XXXX convention (e.g.
  MASWE-0047 ↔ MASWE-0074 now note their intentional security/privacy overlap).

3. Frontmatter/metadata changes

• requirement: added to all 77 weaknesses — a single normative sentence (e.g. "The app
  excludes sensitive data from application logs.") suitable for use as a testable requirement
  statement, positioned right after alias. Now documented as a required field in the authoring
  instructions.
• threat / attacks (new fields): added to all 77 weaknesses, positioned right after
  profiles. threat is a single MAS-THREAT-XXXX ID naming the outcome attackers achieve;
  attacks is a list of MAS-ATTACK-XXXX IDs (ascending order) naming the paths to it. Both
  reference the new threats.yaml / attacks.yaml vocabularies described in §2. Documented as
  required fields in the authoring instructions.
• mappings.maswe-beta: records which old (pre-1.0.0-rc, "beta") MASWE IDs are covered by this
  weakness, for traceability. This started as a top-level beta-coverage field and was later moved
  into mappings and renamed to maswe-beta for consistency with the other mapping fields.
• mappings.masvs-v2 audit: after the mechanical rename, every masvs-v2 control list was
  checked against the actual control definitions (../masvs/controls/*.md) and against a
  never-lose-a-mapping audit of all 119 predecessor files:
  • Controls genuinely inherited from absorbed weaknesses were unioned in (e.g. MASWE-0020 gained
    CWE-287 back after review).
  • Controls that no longer fit the re-scoped weakness were pruned (e.g. MASWE-0025 dropped
    MASVS-AUTH-1, MASWE-0048 dropped MASVS-PLATFORM-1/-3) — see commit 93f0d95 for the
    full rationale per file.
  • Confirmed all 24 MASVS-v2 controls are covered by at least one weakness.
• mappings.android-risks: reviewed all existing links against
  https://developer.android.com/privacy-and-security/risks and added the risk to 12 weaknesses that were
  missing it. All 44 risks on that page are now mapped to at least one MASWE; a few required
  judgment calls that were subsequently refined (e.g. bad-dns → MASWE-0047, broadened to also
  cover under-use of platform-provided secure functionality; unsafe-download-manager →
  MASWE-0041; use-of-native-code → MASWE-0045 and MASWE-0048). The values were also
  simplified from full URLs to the short risk identifiers (e.g. log-info-disclosure instead of
  https://developer.android.com/privacy-and-security/risks/log-info-disclosure), which the site
  renders from.
• mappings.android-core-app-quality (new field): added to 25 Android-relevant weaknesses,
  linking each to the matching item(s) in the
  Android Core App Quality checklist.
  Values use the current named IDs (e.g. Network_Security_Traffic, Minimize_Permissions,
  Cryptographic_Algorithms), and the two pre-existing legacy-style mappings (SC-* / PS-*
  numbering) were migrated to the named IDs. Every checklist item in the "Privacy and security"
  section is now covered by at least one weakness. The field is documented in the authoring
  instructions and is only used when platform includes android.

4. Traceability

Every new weakness's mappings.maswe-beta field lists the old MASWE ID(s) it supersedes or
absorbs, so old-ID → new-ID mapping (and content lineage for merged weaknesses) is fully
recoverable from the files themselves, independent of git history.

Verification performed

• All 77 id: fields match their filename; no duplicate IDs.
• All frontmatter parses as valid YAML.
• All 77 weaknesses are status: new; no placeholder/draft entries and no leftover draft:
  metadata blocks.
• Every weakness has the four required sections in the required order, and each ## Overview opens
  with an "… occurs when …" definition.
• Every weakness's threat: resolves to an entry in threats.yaml and every attacks: ID resolves
  to an entry in attacks.yaml; every ## Impact consequence uses a label from the canonical
  impact.yaml set.
• No stale status: deprecated / covered_by / deprecation_note metadata left behind.
• Zero unpreserved cwe/masvs-v1/masvs-v2 mappings across all 119 predecessor files (full
  audit script run against git history).
• All 24 MASVS-v2 controls, all 44 documented Android risks, and every "Privacy and security"
  Android Core App Quality checklist item are covered by at least one MASWE.

[cpholguera]

Carlos: DONE

[cpholguera]

doesn't sound like attacks

[sgIOlas]

Adding references for standard key attestation

Suggested change

	- https://developer.android.com/google/play/integrity/classic
	- https://developer.apple.com/documentation/devicecheck
	- https://developer.android.com/google/play/integrity/classic
	- https://github.com/android/keyattestation
	- https://source.android.com/docs/security/features/keystore/attestation
	- https://grapheneos.org/articles/attestation-compatibility-guide
	- https://developer.apple.com/documentation/devicecheck

[sgIOlas]

Mention hardware attestation API

Suggested change

Device attestation uses platform services, such as the Android Play Integrity API or iOS DeviceCheck and App Attest, to provide the backend with cryptographically verifiable evidence about the device associated with a request. The evidence and security properties differ by platform and service. Without device attestation, the backend cannot independently verify device-origin claims made by the client. The backend must validate attestation evidence and apply the service-specific request-binding, freshness, and replay protections; client-side evaluation is another bypassable local check.

Device attestation uses platform services, such as the standard Android hardware attestation API, the Play Integrity API or iOS DeviceCheck and App Attest, to provide the backend with cryptographically verifiable evidence about the device associated with a request. The evidence and security properties differ by platform and service. Without device attestation, the backend cannot independently verify device-origin claims made by the client. The backend must validate attestation evidence and apply the service-specific request-binding, freshness, and replay protections; client-side evaluation is another bypassable local check.

[sgIOlas]

Mention hardware attestation API

Suggested change

	On Android, Play Integrity can provide server-verifiable assurance that the device has not been compromised in ways covered by its device-integrity verdicts, such as an unlocked bootloader or an unrecognized operating-system image. On iOS, DeviceCheck and App Attest do not provide equivalent assurance about operating-system compromise. They can establish that evidence originates from genuine Apple hardware; App Attest also binds that evidence to a legitimate app instance, but neither service attests the integrity of iOS.
	On Android, both the hardware-backed attestation and Play Integrity APIs can provide server-verifiable assurance that the device has not been compromised in ways covered by its device-integrity verdicts or signals, such as an unlocked bootloader, an unrecognized operating-system image or an outdated security patch level. Their main differences include:
	- **Google Mobile Services (GMS) Requirement**: Direct hardware-backed key attestation uses Android Keystore and does not require Google Play services on the device to request an attestation. Play Integrity depends on Google Play components and Google services.
	- **Verdict Generation and Policy Enforcement**: With direct key attestation, the backend receives signed properties and defines which boot states, operating-system signing keys, patch levels, and application identities it accepts. Play Integrity evaluates the available signals and returns Google-defined verdict labels. In both cases, the developer decides how the backend responds.
	On iOS, DeviceCheck and App Attest do not provide equivalent assurance about operating-system compromise. They can establish that evidence originates from genuine Apple hardware; App Attest also binds that evidence to a legitimate app instance, but neither service attests the integrity of iOS.

[jacobocasado]

Suggested change

	- **Missing Validation at Trust Boundaries**: Consuming data from the network, backups, external interfaces, files, UI, or IPC without validating type, length, format, and range before use.
	- **Missing Validation at Trust Boundaries**: Consuming data from untrusted boundaries, like network, backups, external interfaces, files, UI, or platform IPC without validating type, length, format, and range before use.

[jacobocasado]

This looks like a generic one while the following bullet points detail a bit more the wording for common vulnerabilities like SQLi, deserialization attacks, etc. I feel that we can leave both, the detailed and the specific ones.

[jacobocasado]

Suggested change

	- **Untrusted Data in Queries**: Concatenating untrusted input into SQL or other queries instead of using parameterized APIs.
	- **Untrusted Data in Queries**: Concatenating untrusted input into queries like SQL queries instead of using parameterized APIs.

[jacobocasado]

Suggested change

	- **Untrusted Paths and Archives**: Using externally supplied file names or paths (e.g. from content providers or zip entries) without canonicalization and containment checks.
	- **Untrusted Paths and Archives**: Using externally supplied file names or paths (e.g. from ZIP entries) without canonicalization and containment checks.

[jacobocasado]

Suggested change

	- **Validate at Every Trust Boundary**: Treat all externally originated data as untrusted, including data received over TLS or restored from backups, and validate it against strict expectations before use.
	- **Validate at Every Trust Boundary**: Treat all externally originated data as untrusted and validate it against strict expectations before use.

[jacobocasado]

Suggested change

	- **Use Parameterized Queries**: Access databases exclusively through parameterized or prepared statements; never build queries by concatenating untrusted input.
	- **Use Parameterized Queries**: Access databases exclusively through parameterized or prepared statements. Do not build queries by concatenating untrusted input.

[jacobocasado]

Suggested change

	- **Canonicalize and Contain Paths**: Canonicalize externally supplied file names and paths and verify they resolve inside the intended directory before any file operation, including when extracting archives.
	- **Canonicalize and Contain Paths**: Canonicalize externally supplied file names and paths and verify they resolve inside the intended directory before any file operation.

[sushi2k]

Suggested change

	- **Custom Credentials Not Keystore-Bound**: Implementing a custom app PIN or password as a plain comparison in code instead of binding it to the platform keystore (e.g. via the Keychain's `applicationPassword` access control).
	- **No Brute-Force Resistance**: Allowing unlimited attempts against a custom PIN or password because the app does not track failures.
	- **Custom Credentials Hardcoded**: Implementing a custom app PIN or password as a plain comparison in code.

[sushi2k]

Suggested change

	- **Require Explicit User Action**: For passive modalities such as face recognition, require explicit confirmation of the authentication prompt before proceeding with sensitive operations.
	- **Require Explicit User Action**: For passive modalities such as face recognition, require explicit confirmation of the authentication prompt before proceeding with sensitive operations.
	- **Resist Credential Guessing**: Keep each attempt dependent on hardware-backed key material so guesses cannot be parallelised off-device, and combine app-defined credentials with a biometric or device-credential constraint so every attempt also requires an OS-throttled factor.

[sushi2k]

Suggested change

- **Restrict Clipboard Scope and Lifetime**: Keep sensitive clipboard items local to the device, set expirations where supported, and clear the clipboard once the data has been used.

- **Restrict Clipboard Exposure**: Prevent copying sensitive values when it is not required for the intended functionality. When copying is a legitimate feature, follow the platform's [secure clipboard handling guidance on Android](https://developer.android.com/privacy-and-security/risks/secure-clipboard-handling) and mark the content using [`ClipDescription.EXTRA_IS_SENSITIVE`](https://developer.android.com/reference/android/content/ClipDescription#EXTRA_IS_SENSITIVE) to obscure clipboard previews. On iOS, use pasteboard options such as [`localOnly`](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/localonly) and [`expirationDate`](https://developer.apple.com/documentation/uikit/uipasteboard/optionskey/expirationdate) to limit cross-device propagation and content lifetime. These mechanisms reduce exposure but do not provide access control over clipboard contents.

[cpholguera]

Carlos: DONE