Improper Credential Usage

M2Inadequate Supply Chain Security

A mobile release depends on SDKs, libraries, build tooling, and signing infrastructure. Third-party SDKs are a particular concern because they typically run with the app's full permissions and often exist to collect data. A compromise anywhere in that chain, including the signing key, ships to every user through the app store as a legitimate update.

M3Insecure Authentication/Authorization

Because the client is under the user's control, any authentication or authorization decision made locally can be bypassed by patching the app or hooking it at runtime. The recurring mistake is treating a local check — a biometric prompt, a role flag, a hidden screen — as though it were an enforced boundary rather than a user-experience affordance.

M4Insufficient Input/Output Validation

Mobile apps consume input from many channels beyond the user interface: deep links, inter-process messages, notifications, files, QR codes, Bluetooth and NFC peripherals, and backend responses. Any of these can carry hostile data, and output rendered into an embedded web view brings the whole class of web injection problems onto the device.

M5Insecure Communication

Mobile devices roam across networks the app cannot trust, so transport security is the only thing protecting data in transit. Failures include plaintext channels, TLS validation that has been weakened or disabled — often a debugging shortcut that survives into release — and sensitive data sent over side channels that bypass the app's main transport entirely.

M6Inadequate Privacy Controls

Mobile devices are dense sources of personal data — precise location, contacts, health metrics, photos, identifiers, and behavioural telemetry — and apps routinely collect more than their function requires. This category covers collection without a clear basis or disclosure, over-broad permissions, sharing with third parties users are unaware of, and retention beyond any real need. The consequences are regulatory as much as technical.

M7Insufficient Binary Protections

A shipped mobile binary is available to anyone, and it can be decompiled to recover logic, strings, and endpoints, or patched and repackaged to remove checks. Binary protections do not make an app secure — they raise the cost of analysis and tampering. The failure mode is relying on them as though they were an access control, or omitting them entirely on an app whose logic is worth attacking.

M8Security Misconfiguration

Mobile platforms expose many security-relevant settings, and permissive defaults or leftover development settings are a common source of exposure. Because these settings are declared in manifests and platform configuration files rather than in application code, they are easy to overlook in code review yet trivially discoverable by anyone inspecting the package.

M9Insecure Data Storage

Apps cache a great deal locally for performance and offline use, and data written to device storage may be readable by other apps on a compromised or rooted device, by backups, or by forensic extraction. The frequent mistake is storing sensitive data in ordinary application storage — preferences, databases, files, or logs — on the assumption that platform sandboxing is sufficient protection.

M10Insufficient Cryptography

Mobile apps commonly attempt local cryptography and get the surrounding details wrong even when the algorithm choice is defensible. The usual problems are key management rather than algorithms: keys derived from device-readable values, stored alongside the data they protect, or hard-coded in the binary. This category also covers obsolete algorithms, unsafe modes, and reused initialisation vectors.