M1

Improper Credential Usage

What it is. Credentials, API keys and tokens hardcoded into the app, or stored and transmitted carelessly.

In a real app. A payment or cloud key sitting in a resource file or plist, readable minutes after decompiling. One large-scale study found more than 815,000 hardcoded secrets across 156,000 iOS apps.

What closes it. No credentials in the binary, keys held in platform key storage, short-lived tokens issued at runtime, and rotation of any key that has ever shipped.

M2

Inadequate Supply Chain Security

What it is. Vulnerable or malicious third-party libraries, SDKs and build tooling.

In a real app. An analytics SDK collecting more than your privacy notice discloses, or an outdated library with a published vulnerability that nobody has patched.

What closes it. A maintained inventory of every dependency and its version, a review of what data each SDK can reach, and signed, reproducible builds.

M3

Insecure Authentication/Authorization

What it is. Weak login and session handling, and authorisation decisions made on the device instead of the server.

In a real app. A feature hidden in the interface but still reachable through the API, or a local biometric check whose result can be hooked and flipped to “passed”.

What closes it. Server-side authorisation on every request, sessions bound to a device, and runtime protection around the authentication flow so it cannot be hooked.

M4

Insufficient Input/Output Validation

What it is. Data accepted from users, deep links, other apps or servers without validation, opening the door to injection.

In a real app. A deep link that opens an in-app web view on an attacker’s page, or input that reaches a local database query unescaped.

What closes it. Validation of every input, including deep links and inter-app messages, encoded output, and web views restricted to the domains you own.

M5

Insecure Communication

What it is. Plaintext traffic, weak TLS configuration, or an app that accepts any certificate.

In a real app. A debug setting that disables certificate validation during testing and quietly ships to production.

What closes it. TLS everywhere, correct certificate validation, and certificate pinning paired with hooking detection, because pinning alone is routinely bypassed. See why certificate pinning fails.

M6

Inadequate Privacy Controls

What it is. Personal data collected, logged, stored or shared beyond what the app needs.

In a real app. Identity numbers written to debug logs, or account statements captured in the app-switcher snapshot.

What closes it. Data minimisation, scrubbed logs, screen-capture protection on sensitive screens, and handling aligned with local data protection law such as Malaysia’s and Singapore’s PDPA.

M7

Insufficient Binary Protections

What it is. A shipped app that can be read and modified: no obfuscation, no integrity checks, no runtime protection.

In a real app. The app is decompiled, the root check is located by name and removed, and a repackaged clone is distributed under your brand. See what hackers see when they decompile your app.

What closes it. Mobile app hardening: obfuscation, code and data encryption, anti-tampering and RASP, with enforcement so that stripping the protection out makes the app alert or exit.

M8

Security Misconfiguration

What it is. Insecure defaults: debuggable builds, exported components, backups enabled, cleartext traffic allowed, over-broad permissions.

In a real app. An exported Android activity that lets another app open an internal screen directly, skipping the login flow.

What closes it. A release-configuration review on every build, enforced by automated checks in the pipeline rather than by memory.

M9

Insecure Data Storage

What it is. Sensitive data stored unencrypted on the device: preferences files, local databases, caches and logs.

In a real app. A session token in plain app storage, readable by anyone with a rooted phone or a device backup.

What closes it. Store as little as possible, encrypt what remains with keys held in Keystore or Keychain, clear caches, and detect rooted and jailbroken devices at runtime. See how root detection works.

M10

Insufficient Cryptography

What it is. Weak or outdated algorithms, hardcoded keys, poor randomness, and home-made cryptography.

In a real app. An encryption key embedded in the code right beside the data it is meant to protect.

What closes it. Platform cryptography APIs, current algorithms, keys in hardware-backed storage, and a firm rule against writing your own.

Map your last penetration test to the Top 10. It shows which risks you have already found, and which nobody has looked for.

Scan every build against MASVS. An annual test finds last year’s issues. A pipeline check finds this sprint’s.

Treat M7 as a release gate. No production build ships without hardening and runtime protection applied.

Keep the evidence. Scan reports, protection settings and runtime detections, dated and exportable, are what an examiner asks to see.

Find M1 to M10 before release. Static and dynamic assessment with OWASP Mobile Top 10 and MASVS coverage, run on every build inside your CI/CD, with findings mapped to remediation. Explore IronScan

Close M7, codelessly. Obfuscation, encryption, anti-tampering and RASP applied to the compiled app, with no SDK and no source-code changes. A proof of concept takes days, not a quarter. Explore IronWall

Prove it on real devices. Every runtime detection logged live across your portfolio, with device details and the action taken, exportable for audit. Explore IronSky