MASVS & Developer Pitfalls · Security Champions

Module 9b · MASVS & Pitfalls

Security Champions · Module 9b

MASVS Framework & Developer Pitfalls

Part 2 — using OWASP MASVS as a practical verification checklist, avoiding common mobile developer mistakes, and building your security pipeline.

1 / 18

Recap · Part 1

Where we left off

Part 1 covered the OWASP Mobile Top 10 — ten categories of risk, from hardcoded credentials (M1) to insufficient cryptography (M10). Two patterns emerged: "insecure" means absent controls; "insufficient" means weak controls.

Part 2 shifts from what can go wrong to how to verify it's right. The tool is MASVS — a structured verification framework that turns the Top 10 risks into actionable checklists.

Part 1 was the threat landscape. Part 2 is the verification discipline — and the developer habits that either support or undermine it.

2 / 18 · Recap

Act 3 · MASVS intro

A checklist, not a policy

MASVS — the Mobile Application Security Verification Standard — is OWASP's answer to a simple question: how do you know your mobile app is secure enough? Not through opinion or intuition, but through a structured list of verifiable requirements.

Unlike the Mobile Top 10 (which describes risks), MASVS describes controls — concrete, testable statements like "the app does not export sensitive data via IPC mechanisms" or "all cryptographic operations use platform-provided implementations."

MASVS defines what to verify (the requirements). MASTG (Mobile Application Security Testing Guide) defines how to test each requirement — specific tools, techniques, and test cases. Think of MASVS as the checklist and MASTG as the lab manual. Your team needs both, but MASVS comes first because it tells you what "done" looks like.

3 / 18 · MASVS

Visual · Three verification levels

MASVS Verification Levels

R · ResilienceAnti-tampering, anti-reverse-engineering

L2 · Defense in DepthThreat model driven. Financial, healthcare, regulated.

L1 · Standard SecurityEvery app. Baseline hygiene. Non-negotiable.

L1

Standard

Every app must pass. Covers storage, network, auth basics. Your CI/CD minimum gate.

L2

Defense in Depth

Threat-model-driven. Certificate pinning, advanced auth, data classification. For apps handling sensitive data.

R

Resilience

Anti-tampering, jailbreak detection, debugger checks. For apps where the binary itself is a target.

Pick the level that matches your threat model, not your ambition. L1 is mandatory for every app. L2 and R add cost — spend it where the risk justifies it.

Notice — the pyramid gets narrower at the top. Fewer apps need R-level resilience. Most need L1 done well.

Time to think and reflect

Act 3 · Storage checks

MASVS-STORAGE

What to verify

The MASVS storage category has the highest failure rate in mobile assessments. These are the checks that matter most:

✗

No sensitive data in logs. Check for NSLog, Log.d, print() statements that output tokens, emails, or session IDs.

✗

No sensitive data in backups. Verify allowBackup=false on Android and exclude sensitive files from iCloud backup on iOS.

✓

Keychain / Keystore for secrets. All tokens, keys, and credentials stored via platform secure storage — not SharedPreferences or NSUserDefaults.

✓

Clipboard cleared. Sensitive fields use secureTextEntry (iOS) or TYPE_TEXT_VARIATION_PASSWORD (Android) to prevent clipboard caching.

Most storage checks can run as SAST rules in your CI/CD pipeline. Tools like MobSF (Mobile Security Framework) scan APK/IPA files and flag storage violations automatically. The champion's job isn't running the tool — it's ensuring the pipeline blocks the build when it finds violations, rather than generating reports nobody reads.

If you use a cross-platform framework, the same MASVS storage requirements apply — but the secure storage APIs differ. React Native: use expo-secure-store or react-native-keychain instead of AsyncStorage for sensitive data. Flutter: use flutter_secure_storage which wraps Keychain (iOS) and EncryptedSharedPreferences (Android). Check that your framework's security bridge actually calls the native platform APIs, not a custom implementation.

5 / 18 · Storage

Act 3 · Crypto checks

MASVS-CRYPTO

What to verify

Cryptography failures aren't about missing encryption — they're about using it incorrectly. MASVS crypto checks catch the implementation mistakes:

✗

No deprecated algorithms. MD5, SHA-1 for security purposes, DES, 3DES, RC4 — all banned. Check dependencies too; an SDK may use weak crypto internally.

✗

No hardcoded keys. Encryption keys stored as string literals in source code. Use platform key generation APIs instead.

✓

Random IVs per operation. AES requires a unique initialization vector for every encryption call. Static IVs mean identical plaintexts produce identical ciphertexts.

✓

Platform crypto APIs. Use Security framework (iOS) or javax.crypto with Android Keystore provider — not custom implementations.

⚠️Hardcoded IV

⚠️ECB mode

✅AES-GCM

✅256-bit key

Remember

Mobile crypto failures are almost always misuse of correct libraries — hardcoded IVs, ECB mode, insufficient key lengths. The fix is a review checklist, not a new library.

6 / 18 · Crypto

Act 3 · Auth checks

MASVS-AUTH

What to verify

Authentication and authorization verification requires testing both the client and the backend. A client-side biometric check without server-side session validation is a UX feature, not a security control.

✓

Server-side session management. All auth decisions enforced on the backend. The client displays UI — the server decides access.

✓

Token expiration and refresh. Short-lived access tokens with server-validated refresh tokens. No eternal sessions.

✗

No client-only authorization. If the app hides a button to restrict access, but the API endpoint accepts the request anyway — that's a BOLA vulnerability, not access control.

!

Biometrics backed by crypto. L2 apps should bind biometric auth to a cryptographic key in the secure enclave — not just a boolean isAuthenticated flag.

Champion's takeaway

Mobile auth is split-brain: the app validates locally, the server validates remotely. Never trust client-side auth decisions — always verify server-side.

7 / 18 · Auth

Best practice · Living checklist

MASVS as a living document

The most common mistake with MASVS: treating it as a one-time audit checklist. Run it once, get a report, file it. Six months later, new features have introduced new storage patterns, new SDKs, new API endpoints — and the report is stale.

The better model: MASVS as a living checklist integrated into your release process. Each release gets a lightweight MASVS pass on the areas that changed. New storage? Run the storage checks. New auth flow? Run the auth checks. Not the full list every time — just the sections that match the delta.

A Champion's role with MASVS: maintain a mapping between your app's features and the relevant MASVS sections. When a feature changes, the corresponding checks are triggered automatically — or at minimum, flagged for manual review.

Some teams maintain a spreadsheet mapping each MASVS requirement to: the feature it applies to, the last time it was verified, the tool or method used, and the result. This sounds bureaucratic, but it takes 30 minutes to set up and converts MASVS from an abstract standard into a concrete, auditable record. When a pentest report asks "do you follow MASVS?" you have a timestamped answer.

8 / 18 · Best practice

Knowledge check · MASVS levels

Knowledge check

Your team builds a banking app that handles financial transactions and stores payment credentials. Which MASVS level is the minimum appropriate verification target?

Correct: B. Financial apps handling transactions and payment credentials fall squarely into L2 territory — defense-in-depth with threat-model-driven controls like certificate pinning, advanced session management, and data classification. L1 alone is insufficient for regulated data. R (resilience) may also apply if the binary processes sensitive algorithms locally, but L2 is the minimum baseline. The levels are additive: L2 includes all L1 requirements.

9 / 18 · Quiz

Act 4 · Pitfall · Client trust

Trusting the client

Developer pitfall

Business logic runs only on the client. The backend trusts whatever the app sends — prices, quantities, authorization flags, feature toggles.

Fix: Server-side enforcement for every decision that affects money, access, or data. The client is a display layer.

This is the single most common mobile development mistake. It manifests differently in every app, but the pattern is identical: a developer implements a check on the client, assumes it's sufficient, and skips the backend validation.

A common variant: premium features "disabled" on the client via a feature flag. The API endpoints for those features still accept requests from any authenticated user. An attacker with a proxy enables the features by flipping the client flag — or just calls the API directly. Feature access must be enforced server-side.

Pattern

Client-side validation is UX, not security. Every check in the mobile app can be bypassed with a proxy. The server is the only trust boundary.

10 / 18 · Pitfall 1

Act 4 · Pitfall · Secrets & AI

Secrets in the age of AI

Developer pitfall

AI-generated code includes placeholder credentials that become production secrets. The LLM suggests an API key format, the developer fills it in, and it ships.

Fix: Pre-commit hooks with secret detection (e.g., gitleaks, trufflehog). Catch secrets before they enter version control.

The AI coding assistant problem is new and subtle. The tool generates code that works — with hardcoded connection strings, API keys in config files, and inline credentials. The developer reviews the logic, not the secrets. The code passes review because the reviewer is checking functionality, not scanning for credential patterns.

Layer 1 — IDE plugin: flag secrets as you type (GitGuardian, GitHub Copilot security). Layer 2 — Pre-commit hook: scan staged files before commit (gitleaks). Layer 3 — CI pipeline: scan the full repo on every PR. Three layers because no single layer catches everything, and developers will bypass any layer that interrupts their flow too aggressively.

Champion's takeaway

AI-assisted reverse engineering makes obfuscation a speed bump, not a wall. Don't store secrets in mobile binaries — assume they'll be extracted.

11 / 18 · Pitfall 2

Act 4 · Pitfall · CI/CD gaps

The pipeline that doesn't block

Developer pitfall

Security scanning runs in CI/CD but only generates reports — it never blocks the build. Teams accumulate findings they never fix because there's no enforcement mechanism.

Fix: Security gates that break the build on critical/high findings. Non-blocking for low/medium — but tracked with SLAs.

The gap between "we run security scans" and "security scans affect our releases" is where most mobile security programs die. A scan that produces a PDF is a compliance artifact. A scan that blocks a release is a security control.

Gate 1: Secret detection (block on any credential found). Gate 2: Dependency check for known vulnerabilities (block on critical CVEs). Gate 3: Configuration validation — debug disabled, ATS enabled, backup disabled. Gate 4: SAST for mobile-specific patterns (block on high). These four gates catch the majority of shippable mobile security issues. They add ~2 minutes to a build.

Practical rule

Mobile CI/CD should include SAST + dependency scanning as blocking gates. A pipeline that only builds and tests is a pipeline that ships vulnerabilities.

12 / 18 · Pitfall 3

Act 4 · Pitfall · Cloud backend

The backend you forgot to secure

Developer pitfall

Mobile teams focus on app security but leave cloud infrastructure with default configurations — open S3 buckets, Firebase rules set to public, misconfigured API gateways.

Fix: Infrastructure-as-code security scanning. Treat backend config as part of the mobile security scope.

A mobile app is only as secure as its backend. Open Firebase Realtime Database rules, publicly accessible S3 buckets storing user uploads, API gateways without rate limiting — these aren't "backend team problems." If the mobile app depends on them, they're mobile security problems.

During development, Firebase rules are often set to { ".read": true, ".write": true } for convenience. This ships to production more than you'd think. A single curl command to your-project.firebaseio.com/.json returns the entire database. Google Cloud's security scanner can detect this, but it needs to be enabled and integrated into the release process — not run quarterly.

Remember

The mobile app's backend API is often less hardened than the web API because teams assume the app is the only client. It isn't.

13 / 18 · Pitfall 4

Visual · Mobile backend surface

The Mobile Backend Attack Surface

📱

App

Client code
SDK data

→

🌐

API

Auth, rate limits
Input validation

→

☁️

Cloud

Firebase rules
S3 permissions
IAM policies

The mobile attack surface doesn't end at the app binary. Your cloud backend configuration is part of your mobile security scope.

Notice — each node glows in sequence. An attacker moves through the same chain, looking for the weakest link.

Time to think and reflect

Knowledge check · Developer pitfalls

Knowledge check

A team runs SAST and dependency scanning in their mobile CI/CD pipeline. Scan results are emailed to the security team weekly. What is the most critical gap in this setup?

Correct: B. The fundamental gap is enforcement, not coverage. Scanning that generates reports without blocking releases is a compliance exercise, not a security control. Critical and high findings should break the build. Medium and low findings get tracked with SLAs. The shift from "we scan" to "scans affect our releases" is where security programs go from aspirational to operational.

15 / 18 · Quiz

Summary · Part 2

What you covered

01: MASVS provides three verification levels — L1 (every app), L2 (defense-in-depth for sensitive data), R (resilience against reverse engineering). Pick the level that matches your threat model.

02: Storage, crypto, and auth each have concrete MASVS checklists. The champion's job is integrating these into the release process, not running them once.

03: Four developer pitfalls dominate mobile security failures: client trust, AI-introduced secrets, non-blocking CI/CD scans, and unsecured cloud backends.

04: The pipeline is the enforcement mechanism. A security scan that doesn't block a release is a report, not a control.

16 / 18 · Summary

Module 9b · Your score

Part 2 Results

Calculating...

17 / 18 · Score

Next · Part 3

Part 3: building your five-step mobile security action plan, the security kernel concept, and completing the Security Champions journey.

18 / 18 · Bridge