OWASP MASVS for small app teams: a practical checklist

If a client, an investor or an enterprise customer has ever sent you a security questionnaire, you have probably met the OWASP MASVS. It is the Mobile Application Security Verification Standard from the OWASP Mobile Application Security project, and it is the common language for mobile app security reviews. It is also long, written for security people, and easy to put off.

This guide cuts it down for a small team: what each category asks for, what you can check yourself in the built .apk or .ipa, and which parts need a specialist.

MASVS in two minutes

The project publishes three things that work together:

• MASVS, the standard: what a well built app should do, grouped into categories.
• MASTG, the testing guide: how to test each point, with tools and steps.
• MASWE, the weakness list: the specific mistakes behind each point.

Version 2 of the MASVS (2023) made the standard shorter and moved the old L1, L2 and R levels out of it; the project now describes testing profiles separately. Version 2.1 (2024) added a privacy category. The categories are:

Category	In plain words
MASVS-STORAGE	Sensitive data stays safe on the device, in logs and in backups
MASVS-CRYPTO	Cryptography is used correctly and keys are kept properly
MASVS-AUTH	Sign in and sessions are handled correctly, mostly on the server
MASVS-NETWORK	All traffic uses TLS and the app trusts the right certificates
MASVS-PLATFORM	Components, WebViews and data shared with other apps are safe
MASVS-CODE	The app runs on supported platform versions and libraries are kept up to date
MASVS-RESILIENCE	The app resists tampering and reverse engineering where that matters
MASVS-PRIVACY	The app collects only what it needs and is open about it

What you can check in the build yourself

A lot of the MASVS is about how the app behaves at runtime and how your server works. But a surprising share of real world findings can be seen in the built file. These are the checks worth doing on every build.

STORAGE

• No API keys, tokens or private keys in the code, resources or bundles. See hardcoded API keys in an APK or IPA.
• On Android, a decision about backups: allowBackup and dataExtractionRules. See what allowBackup really backs up.
• No sample databases, log files or .env files copied into assets.

CRYPTO

• No private keys or certificates with keys in the bundle.
• Keys created and kept in the Android Keystore or the iOS Keychain, not in code. This one needs a code review.

NETWORK

• No plain HTTP: on Android, no usesCleartextTraffic for every host; on iOS, no global App Transport Security switch. See iOS ATS exceptions.
• No trust in user added certificate authorities in release builds (Android network security config, outside debug-overrides).

PLATFORM

• Only the components meant to be reachable are exported. See exported Android components.
• WebView debugging off in release builds.

CODE

• Libraries without known vulnerabilities. Check your dependency versions against public advisories.
• A reasonable minimum OS version. Very old Android versions no longer get security updates.

RESILIENCE

• Not debuggable on Android; no get-task-allow in iOS builds that are not development signed.
• Code shrinking with R8 on in Android release builds; symbols stripped from iOS release binaries.
• Root, jailbreak or tamper detection only if your risk needs it. Most apps do not.

What needs a specialist

Be honest about the rest. These parts of the MASVS cannot be checked by reading a file:

• AUTH: session handling, token expiry, biometric flows and the API behind them. This is server work and needs a test of the running system.
• Runtime storage: what the app actually writes to disk, logs and the clipboard while it runs.
• Certificate handling at runtime: whether pinning, if you use it, really works.
• PRIVACY: what data the app collects and sends, compared with your privacy labels.
• RESILIENCE in depth: whether obfuscation and tamper checks hold up against a real attacker.

For an app handling payments, health data or banking, plan for a professional test of the running app and its backend at least once a year and before big releases. The OWASP MASTG is the reference those testers use.

A routine that fits a small team

1. On every build: an automated check of the built file for the items above.
2. On every pull request: a secret scanner on the repository and a dependency update tool.
3. Before each store release: a short manual pass over new screens that handle personal data.
4. Once a year or before a big launch: an outside test of the running app and the API.

How AppForShare helps with step 1

AppForShare runs a security scan on every uploaded build. It covers the build level checks in this list: hardcoded keys (shown masked), backups, exported components, user added certificates, plain HTTP, WebView debugging, debuggable builds, minimum API, ATS exceptions, get-task-allow, unstripped symbols, an R8 hint, integrity libraries present, and a short dated table of library versions with a public advisory. Each finding carries its MASVS category, so the result reads like the table above.

Free accounts see the counts. Pro ($12 a month) shows each finding with a fix and an AI fix plan. Team ($39 a month) adds the full report grouped by MASVS category, an export as JSON or a printable page you can attach to a client questionnaire, and the findings history across builds. In CI, appforshare security --fail-on block fails the job when something has to be fixed. The docs list every check and its level.

These are MASVS mapped checks on the file. They are not a full MASVS assessment, not a penetration test and not a certification, and they do not add any protection to the app. They make step 1 automatic so the specialist's time goes to steps that need one.

Common questions

Can we say our app is MASVS compliant after the scan?

No. The MASVS is verified by testing the running app against the MASTG. A clean build level scan is a good sign and a useful record, not a compliance claim.

Which MASVS categories does the AppForShare scan cover?

STORAGE, CRYPTO, NETWORK, PLATFORM, CODE and RESILIENCE, at the build level. AUTH and PRIVACY need runtime and server testing.

Where do I start if we have never done any of this?

Start with secrets and plain HTTP. They are the most common and the most costly. Then read security checks before you share a build.

To see your own build sorted by MASVS category, create a free account and upload an .apk or .ipa.