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.