Insecure Communication

M1Improper Credential Usage

Mobile apps frequently need to authenticate to backend services, and the tempting shortcut is to embed a credential in the app. Anything shipped inside a binary is readable by anyone who downloads it, so a hard-coded key is a published key. This category also covers credentials cached insecurely on the device and authentication that can be replayed.

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.

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.