Mobile Security

Mobile Application Security

Rules (for AI agents)

ALWAYS

• Start from the premise that the device belongs to whoever is holding it. The app runs on hardware an attacker can root or jailbreak, instrument at runtime, and read at rest. Everything shipped in the package is extractable, every client-side check is removable, and every local check can be made to return the answer the attacker wants. What you actually control is the backend's willingness to act — so any decision that matters is made server-side, on evidence the server verified.
• Issue short-lived, device-scoped tokens from a backend rather than shipping an API key, signing key, or backend credential in source, resources, strings.xml, BuildConfig, or Info.plist. Anyone can download the package and read it.
• Keep credentials in the platform's hardware-backed store: Android Keystore (EncryptedSharedPreferences with a MasterKey), iOS Keychain with a …ThisDeviceOnly accessibility class — WhenUnlocked where the value is never needed in the background, AfterFirstUnlock where it is. Never SharedPreferences, UserDefaults, a plist, or a file. The store protects a key at rest on an uncompromised device; it does not protect against code running inside your process, which is why the credential should be short-lived regardless.
• Android: give every <activity>, <service>, <receiver> and <provider> an explicit android:exported, defaulting to false. Since API 31 the attribute is mandatory when an intent filter is present — which forces the question to be asked, not answered. An exported component is a public API of your app that any installed application can call.
• Treat data crossing an app boundary as untrusted in both directions: validate every Intent extra and incoming activity payload, send sensitive data with an explicit component rather than an implicit intent any app can register for, and create every PendingIntent as FLAG_IMMUTABLE so the recipient cannot rewrite its contents.
• Verify deep links instead of trusting the scheme. A custom scheme (myapp://) can be claimed by any app that declares it; Android App Links (android:autoVerify) and iOS Universal Links are bound to a domain you control and are the only form carrying an ownership proof. Where the link carries an authentication callback, auth-security owns the state / PKCE check that makes it safe.
• Keep the platform's transport defaults: ATS enabled in Info.plist, an Android networkSecurityConfig that denies cleartext, and any exception scoped to a named host rather than the whole app. Where you add certificate pinning for a backend you own, plan its rotation at the same time — a backup pin for the next certificate, a tracked expiry, and a remote kill-switch. A pin that expires bricks every installed copy until users take a store update, which takes days.
• Decide sensitive actions on server-verified attestation — Play Integrity, App Attest, DeviceCheck — rather than a client-side root or jailbreak check. A check running on the attacker's device is removable in minutes; an attestation is worth something because your server evaluates it. Client-side detection is a speed bump worth having on high-risk apps and is never the decision.
• Bind biometric authentication to a cryptographic operation: a Keystore key created with setUserAuthenticationRequired(true) and used through BiometricPrompt, or a Keychain item guarded by kSecAccessControlBiometryCurrentSet. A boolean returned from a "did the user authenticate" API proves nothing — it can be patched to return true.
• Protect sensitive screens from capture: FLAG_SECURE on Android keeps a view out of screenshots and the recents thumbnail; on iOS, cover the window before the app is backgrounded, because the system snapshots the screen to render the app switcher.
• Strip debug material from release builds — verbose logging, android:debuggable, development endpoints, test credentials. Shrinking and minification (R8, ProGuard) are worth enabling for size and dead-code removal, but treat the renaming as a delay for a reverse engineer rather than a control. Nothing in the package is secret.
• Consult logging-security for what may be logged, with one mobile-specific twist: Logcat and oslog are readable from a connected device without root, so an HTTP logging interceptor left at body level in a release build publishes every request and its Authorization header to anyone with a cable.

NEVER

• Ship an app that trusts any certificate: an empty X509TrustManager implementation, a URLSessionDelegate that accepts every challenge, or ATS disabled app-wide with NSAllowsArbitraryLoads. This is still the most common security defect shipped in mobile apps.
• Set android:allowBackup="true" on an app holding credentials — the backup is readable from a developer machine. Exclude sensitive paths explicitly.
• Load a user-controlled URL into WebView or WKWebView without scheme validation, or enable setAllowFileAccessFromFileURLs / setUniversalAccessFromFileURLs. frontend-security owns what executes inside that web view.
• Assume a cross-platform layer has handled any of this. A React Native JavaScript bundle sits readable inside the package, a Flutter AOT binary still contains its string literals, and plugin storage wrappers differ in whether they reach the hardware-backed store at all. The wrapper does not move the trust boundary.

KNOWN FALSE POSITIVES

• Public identifiers embedded in the binary — an analytics key, a public DSN, a Firebase configuration — belong there. The question is whether the backend authorizes anything on them.
• debuggable on a debug variant is normal; the rule concerns release builds.
• A custom URL scheme for an OAuth callback is expected. The control is state or PKCE verification plus an App Link or Universal Link where the platform supports one — not the absence of the scheme.
• An app that deliberately runs on rooted devices (a developer tool, an emulator build) is not failing the attestation rule. That rule is about what the server decides, and the answer may legitimately be "allow".

Context (for humans)

Mobile security has one property that reorganises everything else: the attacker owns the execution environment. On a server you can reason about what an attacker can reach; on a phone they can attach a debugger to your process, patch a function to return true, dump the keychain on a jailbroken device, and read every string in the binary. No amount of client-side hardening changes that, which is why obfuscation and root detection are cost multipliers rather than controls.

The practical consequence is that mobile findings sort into two piles. The first is "we shipped something we should not have" — a credential in the package, a trust-all certificate handler, an exported component, a body-logging interceptor. Those are real and fixable. The second is "we trusted the client to tell us the truth", and the fix is never in the app: it is a backend that verifies an attestation, issues a scoped short-lived token, and authorizes each request on its own.

Cross-platform stacks deserve their own suspicion. React Native and Flutter move the code, not the boundary — the bundle and the AOT binary are both inside the package, and a storage plugin may or may not reach the hardware-backed store depending on platform and configuration. Check what the plugin actually does rather than what its name suggests.

References

• references/verifying-findings.md — confirm or refute a finding, then lock it
• references/platform-specifics.md — manifest attributes and accessibility classes, pinning configuration per stack, App Link and Universal Link setup, screen-capture APIs, and what React Native and Flutter storage plugins actually use
• checklists/android_manifest.yaml
• checklists/ios_keychain_ats.yaml
• OWASP MASVS v2.0 · MASTG.
• CWE-919 — Weaknesses in Mobile Applications.