Mobile App Security Guide

A mobile app runs on a device you do not control, in the hands of anyone who downloads it, so every secret, check and data store shipped inside the binary should be treated as visible to an attacker. Most serious mobile app failures are not exotic exploits: they are API keys compiled into the package, tokens in plain preferences files, OAuth flows run in embedded web views and APIs that trust whatever the app sends. This guide covers the OWASP MASVS, MASTG and Mobile Top 10 2024, secure storage, network security and pinning, authentication, attestation, tampering resistance, SDKs, privacy and testing. It is written for mobile developers, application security engineers and the leads who sign off releases. Managing the devices themselves is covered in the Mobile Device Security Guide.

Key takeaways

• The client is untrusted by design. Authorisation, limits and fraud decisions belong on the server; the app adds signals, never guarantees.
• Nothing in the binary is secret. Long-lived API keys for cloud services must stay on a backend, because anyone can extract them from the package.
• Use the platform key stores directly. Keychain and Android Keystore; Google deprecated the Jetpack security-crypto library (EncryptedSharedPreferences) in 2025.
• Attestation is a server-side signal. Play Integrity and App Attest help only when your backend verifies the verdict and decides.
• Test against a standard. MASVS v2.1.0 defines what to verify, the MASTG explains how, and MAS profiles set how much resilience an app needs.

The reference standards: MASVS, MASTG and the Mobile Top 10

The OWASP Mobile Application Security (MAS) project publishes three linked resources. The MASVS is the requirement set; the current release, v2.1.0, added the MASVS-PRIVACY group. Version 2.0.0 moved the old L1, L2 and R levels out of the controls and into MAS profiles. The MASTG holds platform-specific knowledge, best practices and tests (MASTG-KNOW, MASTG-BEST, MASTG-TEST) for Android and iOS, and MASWE lists weaknesses under the same eight groups.

MASVS v2 has 24 controls: STORAGE (2), CRYPTO (2), AUTH (3), NETWORK (2), PLATFORM (3), CODE (4), RESILIENCE (4) and PRIVACY (4). The OWASP Mobile Top 10 2024 is an awareness list, not a verification standard; the table maps it to the MASVS groups to test.

Candidates that missed the 2024 list, such as Hardcoded Secrets and Unprotected Endpoints (deep link, activity, service), still deserve test cases.

Secure storage on iOS and Android

MASVS-STORAGE covers data the app stores on purpose (STORAGE-1) and leakage, which happens "typically as a side-effect of using certain APIs or system capabilities such as backups or logs" (STORAGE-2). First, store less.

• Keychain accessibility: Apple lists four levels from most to least restrictive: When Passcode Set, When Unlocked (the default), After First Unlock and Always, which Apple says "isn't recommended". Items ending in ThisDeviceOnly can be restored to the same device but are not migrated to another device from a backup, which is what you want for session material.
• Android Keystore: key material is non-exportable and operations run in a system process, so a compromised app can use keys but not extract them. Authorisations are fixed at creation and enforced outside the app. Check KeyInfo.getSecurityLevel() for TRUSTED_ENVIRONMENT or STRONGBOX.
• EncryptedSharedPreferences status: the androidx.security:security-crypto release notes state "Deprecated all APIs in favour of existing platform APIs and direct use of Android Keystore" (1.1.0-alpha07, April 2025). New code should use Keystore directly; existing code needs a migration plan.
• Leakage paths: logs, crash reporters, keyboard caches, the clipboard, WebView caches, backups and the app switcher screenshot. Use FLAG_SECURE on sensitive Android screens; on iOS, hide sensitive views when the scene moves to the background.

Network security and certificate pinning

MASVS-NETWORK-1 requires all traffic to be secured; NETWORK-2 requires "identity pinning for all remote endpoints under the developer's control". Both platforms offer declarative controls.

• iOS App Transport Security (ATS): on by default since the iOS 9 SDK, ATS requires HTTPS for the URL Loading System. Exceptions live in NSAppTransportSecurity: NSAllowsArbitraryLoads disables it everywhere, NSExceptionDomains scopes exceptions per host, and NSPinnedDomains declares expected certificates without custom code. Treat any global exception as a release blocker.
• Android Network Security Configuration: from Android 9 (API 28), cleartextTrafficPermitted defaults to false; from Android 7.0 (API 24), user-installed CAs are not trusted by default. <debug-overrides> applies only to debuggable builds, so test proxy CAs belong there, never in <base-config>.

Pinning trade-offs

Always ship a backup pin. Android's documentation is explicit: without one, a forced key or CA change means "you must push out an update to the app to restore connectivity". A pin-set expiration date avoids bricking old installs, but the same page warns it "may enable attackers to bypass your pinned certificates". Pinning stops network interception, not a user hooking the app on their own device. The certificate side is covered in the Machine Identity, PKI and Certificate Lifecycle Guide.

Authentication and session handling

• OAuth for native apps (RFC 8252, BCP 212): "native apps MUST use an external user-agent" and "MUST NOT use embedded user-agents" for authorisation requests. That means ASWebAuthenticationSession on iOS and Custom Tabs on Android, typically through the OpenID Foundation's AppAuth libraries. An embedded WebView lets the app read the password and breaks single sign-on.
• PKCE is mandatory: RFC 8252 says "Public native app clients MUST implement the Proof Key for Code Exchange", and RFC 9700 requires it for all public clients, with S256. It defeats code interception by another app registered for the same redirect.
• Redirect URIs: prefer claimed HTTPS redirects (Universal Links, verified App Links). Private-use schemes must be reverse-domain (com.example.app:/callback), and any app can register them.
• Passkeys: Authentication Services on iOS and Credential Manager on Android expose passkeys bound to your web domain, removing the phishable password. See the Passwordless and Passkeys Guide.
• Biometric unlock done properly: a prompt that returns a boolean can be hooked. MASVS-AUTH-2 expects local authentication to unlock a key store key that signs or decrypts something the server checks.
• Tokens: keep access tokens short-lived and in memory, refresh tokens in the key store, and rotate or sender-constrain refresh tokens as RFC 9700 requires for public clients. Step up (MASVS-AUTH-3) before payments, payee changes or credential resets. See the Token and Session Security Guide and the OAuth 2.0 and OpenID Connect Guide.

Where identity fits: secrets shipped inside apps

A mobile app is a non-human client, and the credentials it carries are non-human identities with the widest possible distribution: anyone can run a decompiler such as jadx and read them. RFC 8252 says a secret in a widely distributed app "should not be treated as confidential".

• The pattern repeats: the Mobile Apps Hard-Coded AWS Keys 2022 research found cloud credentials in 1,859 Android and iOS apps, and the iOS Apps Leaking Hard-Coded Secrets 2025 analysis of 156,000 App Store apps found the same problem years later. The Rabbit R1 Hard-Coded API Keys 2024 case shows third-party service keys (text-to-speech, maps, cloud) exposed once client code leaked.
• Proxy, do not embed: calls to cloud storage, LLM APIs, payment providers and messaging services go through your backend, which authenticates the user and holds the real key in a vault. See the API Key Management Guide and the Secrets Management Guide.
• Keys that must ship: some client keys are designed to be public (maps SDKs, Firebase configuration). Restrict them by app signature, bundle ID and API scope, because "public" keys can gain power when services change, as the Google API Keys Exposure 2026 showed.
• Short-lived credentials: where an app needs direct cloud access, issue scoped, short-lived tokens after sign-in and attestation, not a static key.
• Signing keys: the app signing key and the CI account that uploads builds are high-value NHIs; hold them in a managed signing service or HSM. See the CI/CD Pipeline Identity Security Guide.

Platform interaction: deep links, intents, WebViews and the UI

MASVS-PLATFORM covers inter-process communication (PLATFORM-1), WebViews (PLATFORM-2) and the user interface (PLATFORM-3). These are where other apps on the same device attack yours.

• Deep link hijacking and scheme squatting: Google's guidance notes that "Android allows multiple apps to register intent filters for the same deep link URI". Use verified App Links (android:autoVerify="true" with a Digital Asset Links file) and Universal Links, never deliver bearer tokens or magic-link codes through a custom scheme, and validate every parameter against an allowlist while checking authentication state before acting on it.
• Intent spoofing and interception: set android:exported="false" on every activity, service, receiver and provider that does not need to be reachable, protect the rest with signature-level permissions, use explicit intents for internal calls and PendingIntent.FLAG_IMMUTABLE.
• Activity and task hijacking: a malicious app can insert a look-alike activity into your task stack (task impersonation). Set android:taskAffinity="", avoid unnecessary singleTask launch modes and target current API levels.
• WebView injection: keep JavaScript off unless required, never load untrusted URLs into a WebView with an addJavascriptInterface bridge, call setAllowFileAccess(false), and use WKWebView on iOS. Attacker content plus a bridge gives the attacker the app's privileges.
• UI exposure: mask sensitive fields, block screenshots and screen recording on sensitive screens, and detect overlays on Android before high-value actions. Malware overlay techniques are covered in the Mobile Malware Guide.

Attestation, tampering and reverse engineering

MASVS-RESILIENCE has four controls: platform integrity (root and jailbreak detection), anti-tampering, anti-static analysis (obfuscation) and anti-dynamic analysis (debugger and hooking detection). They raise cost but do not make the client trustworthy: Frida can hook a function that reports "not rooted", and root-hiding tools disguise root indicators. Any check whose result stays on the device will be bypassed, so move the decision to the server.

• Play Integrity practice: prefer standard requests, never cache verdicts ("Caching integrity verdicts increases the risk of proxying"), hash request data before passing it, and plan for outages and the default 10,000 requests per day quota. Google says to use it "not as your sole anti-abuse mechanism".
• App Attest practice: an app cannot check itself because "a compromised app can falsify the results". Check isSupported with a fallback, use a fresh server challenge of at least 16 bytes, and expect new keys after reinstall or restore.
• Choose resilience by profile: obfuscation, anti-hooking and RASP suit banking, payments, gaming and DRM apps facing repackaging and automated fraud. For most apps, L1 or L2 controls plus server-side checks are the better investment. See the Device Intelligence and Fingerprinting Guide for how these signals feed fraud decisions.

Third-party SDKs and privacy

Analytics, advertising, crash and payment SDKs run with your app's permissions and send data to their own backends. MASVS-CODE-3 requires components without known vulnerabilities; MASVS-PRIVACY covers minimisation, preventing user identification, transparency and user control.

• Inventory and SBOM: keep a bill of materials per build, including transitive dependencies, and review each SDK's destinations and permissions before adoption. See the Open Source Security Guide.
• Apple privacy manifests: PrivacyInfo.xcprivacy declares NSPrivacyTracking, NSPrivacyTrackingDomains, NSPrivacyCollectedDataTypes and NSPrivacyAccessedAPITypes (required reason APIs). Apple lists SDKs that must ship a manifest and signature; if tracking permission is not granted, requests to declared tracking domains fail.
• Store disclosures: the App Store privacy label and Google Play Data safety section must match what the app and its SDKs actually collect. Verify with traffic captures, not SDK marketing pages.
• Minimise permissions and identifiers: request permissions at the point of use, prefer approximate location and photo pickers, and avoid persistent hardware identifiers. See the Privacy Programme Guide for Security Teams.

Testing, vetting and rollout

Combine static analysis (package scanning for secrets, exported components and insecure flags, for example with MobSF), dynamic testing on rooted or jailbroken devices with an intercepting proxy and Frida, and manual MASTG tests for the controls in your profile. Enterprises vetting apps they did not build can follow NIST SP 800-163 Rev. 1.

1. Classify the app: pick a MAS profile (L1 baseline, L2 for sensitive data, R where reverse engineering is a business threat) and record the decision.
2. Fix the cheap, high-impact items first: remove hard-coded secrets and rotate them, turn off cleartext and global ATS exceptions, move tokens into Keychain or Keystore, set exported correctly.
3. Move OAuth to RFC 8252: external user-agent, PKCE S256, claimed HTTPS redirects; test with an old app version still in use.
4. Add attestation in observe mode: call Play Integrity and App Attest, verify on the server and log verdicts without enforcing for two to four weeks to measure false positives by device population.
5. Enforce in rings: enforce on the highest-value endpoints first, with a server-side feature flag so you can roll back without shipping a new build; keep a minimum supported app version (MASVS-CODE-2) so old, weaker clients can be retired.
6. Gate releases: run automated scans in CI on every build and full MASTG testing before major releases or when authentication, storage or networking code changes.

Small versus large organisations: a small team gets most of the value from platform defaults, AppAuth, key stores, a CI secrets scan and server-side attestation. A large organisation should add a shared mobile security library, central pin management, SDK approval and a release gate tied to the MAS profile.

Detection and measurement

Log attestation verdicts, token refresh anomalies, outdated app versions, client-reported pinning failures and API calls that skip expected app flows.

• Secrets in builds: number of secrets found per release scan, target zero long-lived cloud credentials.
• Attestation coverage: percentage of sensitive API calls carrying a verified Play Integrity or App Attest result.
• Version hygiene: share of active sessions on app versions below the minimum supported version.
• MASVS coverage: percentage of controls in the app's profile tested in the last major release, and open high findings past their SLA.
• SDK inventory: SDKs with a reviewed data flow and privacy declaration as a share of all SDKs shipped.

Framework mapping

In NIST CSF 2.0 terms these sit mainly under PR.DS (data security) and PR.PS-06 (secure software development practices).

Common failure patterns

• Cloud keys in the package: a storage or AI API key compiled in "temporarily" ships to every user, as the Mobile Apps Hard-Coded AWS Keys 2022 research showed at scale.
• Security decisions on the client: limits or role checks enforced only in app code are bypassed with a hook or a modified request.
• Debug settings in release: debug trust anchors in base-config, NSAllowsArbitraryLoads left on, or a debuggable build published.
• Pinning without a backup pin: a routine certificate renewal takes the app offline until users update.
• Attestation checked on the device: the app acts on the verdict locally, so the check is patched out.
• Embedded WebView login: credentials pass through app code and users cannot tell a genuine page from a look-alike.

Practitioner checklist

• Assign each app a MAS profile and test the MASVS controls it requires.
• Scan every build for secrets; rotate any found and proxy third-party APIs through your backend.
• Keep tokens and keys in Keychain (ThisDeviceOnly) or Android Keystore; plan migration off EncryptedSharedPreferences.
• Disable cleartext and global ATS exceptions; keep debug trust anchors in debug-overrides.
• If you pin, pin public keys with a backup pin and a rotation runbook.
• Use RFC 8252 OAuth with PKCE S256 and claimed HTTPS redirects; offer passkeys.
• Verify Play Integrity and App Attest on the server, starting in observe mode.
• Set exported explicitly, use verified links and lock down WebViews.
• Keep an SBOM and privacy review for every SDK, reconciled with store privacy labels.
• Enforce a minimum supported app version.

Standards and references

• OWASP: Mobile Application Security Verification Standard (MASVS)
• OWASP: Mobile Top 10 2024
• IETF: RFC 8252 OAuth 2.0 for Native Apps
• Android Developers: Android Keystore system
• Android Developers: Network security configuration
• Android Developers: Play Integrity API overview
• Apple Developer: Establishing your app's integrity (App Attest)
• NIST: SP 800-163 Rev. 1 Vetting the Security of Mobile Applications

Related NHI Mgmt Group resources: Mobile Device Security Guide · Mobile Malware Guide · API Key Management Guide · OAuth 2.0 and OpenID Connect Guide · Secrets Management Guide