Why it matters

Each OS release fixes vulnerabilities and tightens defaults, and many protections apply only to apps that target a recent version. Supporting very old OS versions keeps users exposed to known attacks and forces the app to work without newer controls.

How to meet it

  • Target the current platform SDK, as store policies require, and raise the minimum supported version on a published schedule.
  • Review the behavior changes of each new target version, since many security defaults apply only when you target it.

MASTG tests in the local projects

Neither local project runs a MASTG test for MASVS-CODE-1. The guides below explain the platform mechanisms, and the control’s page on mas.owasp.org links the MASTG tests and weaknesses OWASP maps to it.

Guides on this site

Also covers this · Guide

Harden an Android app's storage, network and entry points

Encrypt local secrets with Android Keystore keys now that Jetpack Security is deprecated, set transport policy in Network Security Configuration, close exported components and mutable PendingIntents, confine WebViews, verify App Links and judge Play Integrity verdicts on the server, mapped to OWASP MASVS 2.1.

Practice

Gaps on this site

The Android guide sets the target SDK. No guide here explains how to choose and raise a minimum supported OS version, or covers this on iOS.

References

  1. MASVS-CODE-1 (OWASP MASVS v2.1.0)
  2. MASVS-CODE: Code Quality (OWASP MASVS v2.1.0)

List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.

Control statements are quoted from OWASP MASVS v2.1.0, licensed CC BY-SA 4.0; the rest is this site's summary. MASTG tests are those the iOS and Android projects here run, with their titles from mas.owasp.org. License.