A mobile app cannot be patched centrally. Users update when they update. MASVS-CODE-1 and CODE-2 answer that by asking for an up-to-date platform requirement and a way to force app updates. Build a version gate your backend controls, and decide in advance when you will use it.
What the controls say
MASVS-CODE-1: the app requires an up-to-date platform version. The description says every OS release includes security patches and new security features, and that by supporting older versions apps stay vulnerable to well-known threats.
MASVS-CODE-2: the app has a mechanism for enforcing app updates. The description says that when a critical vulnerability is found in production, there should be a way to force users to update before they can continue using the app.
The OWASP cheat sheet makes the same point from the operations side: plan regular patches and force updates when needed, since app store review and user adoption cause delays.
Why a forced update path matters
Think about the timeline of a bad bug. You find it, fix it, ship it to the stores, wait for review, and then wait for users to install. Until they do, the old version runs against your backend. If you cannot force an update, you only have the option of changing the server to refuse risky behavior, which may break the old app anyway.
A version gate gives you a third option.
A simple design
- Send the app version with every API request, in a header or the auth token claims.
- Keep a minimum supported version on the server, configurable without a release.
- Return a specific error when the version is below the minimum, such as an HTTP status and a code the app understands.
- Show a clear screen in the app with a button to the store listing. Do not let the user continue into broken flows.
- Optionally add a soft level: a recommended version that shows a dismissible banner.
- Add a minimum OS version the same way for CODE-1, and a plain message explaining that the user's OS is too old for the app.
Test the gate in staging by lowering the minimum to a version you still have installed.
Policy questions to settle now
- Who can raise the minimum, and how fast? Name an owner and an approval path.
- What counts as critical enough to force? Write a short threshold: for example, any bug that exposes user data or lets another party act as the user.
- How do you support users who cannot update, such as someone on an old device? You may need to offer a web alternative or accept the loss.
- How long do you support an OS version after the vendor stops patching it? Pick a rule and publish it.
- How do you communicate? Prepare the in-app text and a status page note before you need them.
Pitfalls
- A gate that depends on a service which can itself be down. Decide whether the app fails open or closed, and for which features.
- Forcing updates for small reasons. Users learn to hate the screen and review scores suffer.
- Forgetting offline-first apps, which may not reach the server for days.
- Breaking the gate with a bad deploy. Add an automated test that a current version passes.
Quick check
Do the app stores force updates for me?
Store features and their limits change, so check the current options for each platform. A gate you control, driven by your own backend, does not depend on them.
Should the gate fail open or closed?
It depends on the risk. Many teams fail open for general screens and closed for sensitive operations. Decide it explicitly.
Sources
Last reviewed: 19 October 2026.
