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]

doesn't sound like attacks

[sushi2k]

Suggested change

	cwe: [287, 778]
	cwe: [451, 778]

[cpholguera]

Suggested change

The clipboard is a shared resource: other apps can read its contents, and on some platforms, clipboard content synchronizes to nearby devices via a universal clipboard. Copying sensitive data such as passwords, one-time codes, card numbers, or tokens to the clipboard, failing to mark it as sensitive, or leaving it there indefinitely can leak that data to other apps and devices.

The clipboard is a shared resource: other apps can read its contents, and on some platforms, clipboard content synchronizes to nearby devices (e.g. the iOS [Universal Clipboard](https://support.apple.com/en-us/102430)). Copying sensitive data such as passwords, one-time codes, card numbers, or tokens to the clipboard, failing to mark it as sensitive, or leaving it there indefinitely can leak that data to other apps and devices.

[sushi2k]

Should be removed. That should be covered in MASWE-0028 | Sensitive Data Exposed via the User Interface

Suggested change

- **Sensitive Data in the Confirmation Prompt**: Displaying sensitive information through the trusted confirmation prompt, which protects the integrity of the confirmation but is not a secure display channel for secrets.

[sushi2k]

Suggested change

- **Do Not Display Secrets in the Prompt**: Keep sensitive information out of the trusted confirmation message; it guarantees integrity of the confirmation, not confidentiality of its contents.

[cpholguera]

Suggested change

	- **Avoid Sticky Broadcasts**: Use regular broadcasts protected with permissions, or more targeted mechanisms, instead of [deprecated](https://developer.android.com/privacy-and-security/risks/sticky-broadcast#overview) sticky broadcasts.
	- **Avoid Sticky Broadcasts**: Use regular broadcasts protected with permissions, or more targeted mechanisms, instead of deprecated sticky broadcasts.

[cpholguera]

Suggested change

	- **Sticky Broadcasts**: Using sticky broadcasts, which remain accessible after delivery and can be read or replaced by any app.
	- **Sticky Broadcasts**: Using [sticky broadcasts](https://developer.android.com/privacy-and-security/risks/sticky-broadcast), which remain accessible after delivery and can be read or replaced by any app.

[cpholguera]

Suggested change

	- https://support.google.com/faqs/answer/9095419
	- https://support.google.com/faqs/answer/9095419
	- https://developer.android.com/develop/ui/views/layout/webapps/native-api-access-jsbridge
	- https://developer.android.com/reference/androidx/webkit/WebViewCompat#addWebMessageListener(android.webkit.WebView,java.lang.String,java.util.Set%3Cjava.lang.String%3E,androidx.webkit.WebViewCompat.WebMessageListener)
	- https://developer.apple.com/documentation/webkit/wkscriptmessagehandler

[sushi2k]

Suggested change

	cwe: [200, 276, 284, 285, 287, 732, 749, 923, 925, 926]
	cwe: [306, 749, 862, 863, 923, 926, 939, 940]

[cpholguera]

Suggested change

	- **Return Data Through Scoped Replies**: Use reply mechanisms scoped to the calling message (e.g. script message handlers with replies) instead of injecting sensitive data into the page's global context.
	- **Prefer Modern Messaging APIs**: On Android, prefer [`WebViewCompat.addWebMessageListener`](https://developer.android.com/reference/androidx/webkit/WebViewCompat#addWebMessageListener%28android.webkit.WebView,java.lang.String,java.util.Set,androidx.webkit.JavaScriptExecutionWorld,androidx.webkit.WebViewCompat.WebMessageListener%29) over the legacy [`WebView.addJavascriptInterface`](https://developer.android.com/reference/android/webkit/WebView#addJavascriptInterface%28java.lang.Object,java.lang.String%29). On iOS, use [`WKScriptMessageHandlerWithReply`](https://developer.apple.com/documentation/webkit/wkscriptmessagehandlerwithreply) when JavaScript requires a native response, and use [`WKScriptMessageHandler`](https://developer.apple.com/documentation/webkit/wkscriptmessagehandler) for one way messages.
	- **Isolate App Owned Bridge Scripts**: When the bridge is intended only for app injected JavaScript, register the handler and injected script in a named execution world. Use [`JavaScriptExecutionWorld`](https://developer.android.com/reference/androidx/webkit/JavaScriptExecutionWorld) on Android and [`WKContentWorld`](https://developer.apple.com/documentation/webkit/wkcontentworld) on iOS, where supported. Keep origin restrictions, frame checks, and message validation in place, because execution world isolation is not origin authorization.

[sushi2k]

Suggested change

	platform: [android, ios]
	platform: [android]

[sushi2k]

Suggested change

	cwe: [200]
	cwe: [829]

[cpholguera]

Suggested change

	## Modes of Introduction
	- **Over-Exposed Bridges**: Exposing more native functionality through the bridge than the web content actually needs.
	- **Bridges Reachable by Untrusted Content**: Making bridge interfaces available to any page the WebView loads instead of restricting them to trusted origins.
	- **Sensitive Data in Bridge Replies**: Returning sensitive data into the WebView's JavaScript context in a way that any content running in the page can read.
	## Modes of Introduction
	- **Over-Exposed Bridges**: Exposing more native functionality through the bridge than the web content actually needs.
	- **Bridges Reachable by Untrusted Content**: Making bridge interfaces available to any page, origin, or frame the WebView loads instead of restricting them to trusted origins.
	- **Unvalidated Bridge Messages**: Accepting message names, arguments, or payloads without validating their structure, types, values, authorization, and expected application state.
	- **Globally Exposed Bridge Mechanisms**: Using bridge mechanisms that expose native interfaces broadly across the WebView, such as Android `addJavascriptInterface`, when origin-scoped messaging APIs are available.
	- **App-Owned Bridge Scripts in the Page World**: Running injected bridge scripts in the same JavaScript execution world as page content, allowing page scripts, including third-party scripts, to access or interfere with the bridge.
	- **Sensitive Data in Bridge Replies**: Returning sensitive data into the WebView JavaScript context through injected scripts, global callbacks, or other mechanisms that unrelated page scripts can read.

[serek8]

• Over-Exposed Bridges: Exposing more native functionality through the bridge than the web content actually needs.

Not sure if the order matters but I wouldn't put it as the most important

[cpholguera]

Suggested change

	This weakness occurs when an app exposes sensitive native functionality to the web content rendered in its WebViews, most commonly through JavaScript bridges.
	Bridges such as `addJavascriptInterface` on Android or script message handlers and JavaScript evaluation on iOS let web content invoke native code. When such bridges expose more capability than needed, or are reachable by untrusted content, malicious JavaScript can invoke native methods, access sensitive data, or perform privileged actions with the app's identity.
	This weakness occurs when an app exposes sensitive native functionality to content loaded in its WebViews, most commonly through JavaScript bridges.
	Bridges such as [`addWebMessageListener`](https://developer.android.com/reference/androidx/webkit/WebViewCompat#addWebMessageListener%28android.webkit.WebView,java.lang.String,java.util.Set%3Cjava.lang.String%3E,androidx.webkit.WebViewCompat.WebMessageListener%29) on Android and [`WKScriptMessageHandler`](https://developer.apple.com/documentation/webkit/wkscriptmessagehandler) on iOS allow web content to send messages to native code. When these bridges expose more capability than necessary, or are reachable by untrusted content, malicious JavaScript can invoke native functionality, access sensitive data, or perform privileged actions using the app's permissions and privileges.

[cpholguera]

Suggested change

	WebViews run with app-specific privileges and often use JavaScript bridges to communicate between the web sandbox and the app to access contacts, local files, the device location, or its camera. Loading untrusted content into WebViews is therefore more dangerous than opening it in an external browser.
	WebViews run with app-specific privileges and often use JavaScript bridges (see @MASWE-0036) to communicate between the web sandbox and the app to access contacts, local files, the device location, or its camera. Loading untrusted content into WebViews is therefore more dangerous than opening it in an external browser.

[cpholguera]

and 0035 (intents)? and MASWE-0048 Unsafe Handling of Untrusted Data?

[TheDauntless]

Suggested change

- **Detect Tampering with Obfuscated Code**: Add self-checks that detect modification or unpacking of obfuscated code and trigger a response (see @MASWE-0064).

[TheDauntless]

Suggested change

	- **Compromise of System Integrity and Business Operations**: Modified clients, cracked features, and clone apps circulate under the app's brand, resulting in revenue loss and reputational damage for the app owner.
	- **Compromise of System Integrity and Business Operations**: Modified clients, cracked features, and cloned apps circulate under the app's brand, resulting in revenue loss and reputational damage for the app owner.

[TheDauntless]

Suggested change

	- **Bypass of Protection Mechanisms**: Attackers can strip security controls from a repackaged copy that still works against the backend, resulting in the circumvention of the app's defenses at scale.
	- **Bypass of Protection Mechanisms**: Attackers can strip resiliency controls from a repackaged copy, making it easier to further analyze and reverse-engineer the application.

[TheDauntless]

Suggested change

	- **Respond Proportionately**: Warn the user, require additional verification, restrict functionality, or block sensitive operations when a hostile environment is detected.
	- **Assess Effectiveness**: Validate the detection against current malware behaviors and update it as the threat landscape evolves.
	- **Respond Proportionately**: Warn the user, require additional verification, restrict functionality, or block sensitive operations when a hostile environment is detected.
	- **Lock Down Account**: Apply restrictions to the account, not just the local client. This will prevent attackers from performing actions on a non-hostile environment after the initial compromise.
	- **Assess Effectiveness**: Validate the detection against current malware behaviors and update it as the threat landscape evolves.

[TheDauntless]

Suggested change

	- **No Response Strategy**: Detecting a hostile environment but not warning the user or restricting sensitive functionality.
	- **No Response Strategy**: Detecting a hostile environment but not warning the user or restricting sensitive functionality.
	- **Insufficient Response Strategy**: Only responding on the current device, rather than on the account level. Malware will often intercept credentials and use them to onboard a legitimate app onto an attacker-controlled device. As part of the response strategy, risky behaviour (such as onboarding the app on a new device) must be blocked in case of a suspected compromise.

[TheDauntless]

Suggested change

	Examples of such information include last connection status, read receipts, birthday, email address, or discoverability settings. Ensuring that users have clear and granular options, typically in the form of app settings, to control data visibility is critical to maintaining their privacy and building trust in the app.
	Examples of such information include last connection status, read receipts, date of birth, email address, or discoverability settings. Ensuring that users have clear and granular options, typically in the form of app settings, to control data visibility is critical to maintaining their privacy and building trust in the app.

[TheDauntless]

Suggested change

- **Oversharing by Default**: Designing sharing flows that expose more than the user intends because privacy-reducing options are off by default or hard to find. For example, forwarding a message or picture that reveals the original sender's name unless the user explicitly enables an option such as "Hide Sender Name".

Since this is part of MASWE-0079 ?

[TheDauntless]

Suggested change

- **Default to Privacy-Friendly Settings**: Set default privacy settings to the most restrictive options, allowing users to opt in to sharing specific information rather than having to opt out, which helps to ensure user privacy by default.

Since this is now MASWE-0079 (Unsafe Defaults for Privacy Relevant Actions)?

[TheDauntless]

Suggested change

	This weakness occurs when an app requests more permissions than it needs, keeps permissions it no longer needs, or fails to explain why permissions are required.
	This weakness occurs when an app requests more permissions than needed, keeps permissions it no longer needs, or fails to explain why permissions are required.

[serek8]

Suggested change

	title: Sensitive Functionality Exposed in WebViews
	title: Sensitive Native Functionality Exposed in WebViews

Everything you write below you about accessing native code from the webview. In this case, should we update the title?

[serek8]

Suggested change

	- **Sensitive Data in Bridge Replies**: Returning sensitive data into the WebView's JavaScript context in a way that any content running in the page can read.
	- **Sensitive Data in Bridge Replies**: Returning sensitive data into the WebView's JavaScript context in a way that any untrusted script can read, regardless of user authentication state.

[serek8]

• Over-Exposed Bridges: Exposing more native functionality through the bridge than the web content actually needs.

Not sure if the order matters but I wouldn't put it as the most important