Mobile App Security · Rolling Thunder Security

The platform sandboxes apps from each other. The platform cannot protect the app from itself. If your banking app stores the PIN in NSUserDefaults, sends API calls over plain HTTP, or implements its own crypto, none of that touches the sandbox — the bug is inside your app's container. This page covers the common ways mobile apps fail at the application layer, and the safer patterns to reach for instead.

Secure storage

Mobile apps need to store credentials, session tokens, API keys, and (sometimes) sensitive user data. Where you put it matters.

iOS — Keychain

The Keychain is the platform's secure storage facility. Hardware-encrypted (Secure Enclave when available), survives app reinstall by default, supports access control (require biometric, require device unlock).

Use for: auth tokens, passwords, cryptographic keys. Avoid: NSUserDefaults (preferences file, world-readable on a jailbroken device), file system without explicit encryption.

Android — Keystore

The Android Keystore stores cryptographic keys backed by TEE or StrongBox. The keys themselves never leave the secure hardware; the app asks the Keystore to sign or encrypt with them.

Use for: encryption keys, with which you then encrypt other data stored in app-internal files. Avoid: SharedPreferences for secrets, files on external storage, hard-coded API keys in strings.xml.

Inter-process communication

Mobile apps don't live alone. Email apps share with calendar apps; browsers open into payment apps. The OS provides structured IPC mechanisms — and each one is a potential attack surface when handled carelessly.

URL schemes & deep links. An app registers myapp://; any other app can launch it with parameters. Trust nothing from a URL. The parameters are attacker-controllable. Universal Links (iOS) and App Links (Android) require the calling app's domain to be verified against the receiving app's apple-app-site-association or assetlinks.json file — preferable to legacy URL schemes for any security-sensitive flow.
Intents (Android). Apps export Activities, Services, and BroadcastReceivers. By default, exported components accept Intents from any app on the device. Mark components android:exported="false" unless they explicitly need to be callable; for exported ones, validate every input as if it came from the network.
Content Providers (Android). The CRUD-over-URI mechanism that lets apps share structured data. Famous for SQL injection bugs when the URI's query parameters get concatenated into a SQL statement. Use parameterized queries; restrict provider permissions.
Pasteboard (iOS) / Clipboard (Android). Anything copied is readable by any other app. iOS 14 added a banner notifying users when an app reads the clipboard — both because of TikTok's overzealous reads and because the clipboard had become a side channel for tracking. Don't put secrets in the clipboard unless you have to, and clear them quickly.

OWASP Mobile Top 10

OWASP maintains a Mobile Top 10 (most recently refreshed in 2024). The categories don't change much year-over-year because the bugs don't change much either:

Improper Credential Usage. Hard-coded API keys, OAuth secrets in the APK, basic-auth credentials in plain config files. Anyone who extracts the binary can read them.

Inadequate Supply Chain Security. The mobile equivalent of NPM and PyPI — SDKs from third-party advertisers, analytics, social SDKs that the app developer didn't audit. The Joker malware family lived in advertising SDKs for years.

Insecure Authentication / Authorization. Locally-validated logins (the password is checked client-side; the server accepts whatever the client claims), API endpoints with no per-request auth checks, JWT tokens that never expire.

Insufficient Input/Output Validation. SQL injection in Content Providers, XSS in WebView contexts, deep-link parameters fed directly to dangerous APIs. The bugs are the same as web; the surface is different.

Insecure Communication. HTTPS not enforced, certificate pinning not implemented (or pinned to roots, not specific certs), legacy ciphers. NSAllowsArbitraryLoads set to true to "make it work" during development and never removed.

Inadequate Privacy Controls. Collecting more data than necessary, sharing with third parties without disclosure, tracking that violates platform rules (App Tracking Transparency, Play Store policy).

Insufficient Binary Protections. No code obfuscation, no anti-tampering, no jailbreak/root detection — making reverse engineering and modification trivially easy. Not a substitute for server-side security, but a layer.

Security Misconfiguration. Debug logs enabled in release builds, android:debuggable="true" in production, screenshot caching of sensitive screens, allowing backups of app data via android:allowBackup.

Insecure Data Storage. Storing tokens in plaintext files, in SharedPreferences/NSUserDefaults instead of Keystore/Keychain, on external storage where any app can read them.

M10

Insufficient Cryptography. Custom crypto, ECB mode AES (the penguin shows through), fixed IVs, hardcoded keys, short keys. The shape of crypto failure on mobile is identical to crypto failure everywhere else.

WebView caveats

Many mobile apps embed a WebView — a browser engine inside the app — to render HTML content. WebViews are powerful and dangerous in equal measure:

JavaScript bridges. Apps that expose native APIs to WebView JavaScript (addJavascriptInterface on Android, WKScriptMessageHandler on iOS) hand the WebView the ability to call into native code. A compromised WebView (XSS, malicious page) reaches the app's privileges.
Loading untrusted content. An app that loads https://anywhere in a WebView is effectively a browser with no protections. Restrict to known origins.
File access. WebView settings like allowFileAccess, allowContentAccess, allowFileAccessFromFileURLs can grant the embedded page access to the device filesystem. All off by default in modern SDKs; verify they stay off.
SafeBrowsing. Android WebView has Safe Browsing enabled by default; iOS WKWebView uses Safari's protections. Don't disable them.

Mobile pen-test tooling worth knowing. Frida (dynamic instrumentation), Objection (Frida wrapper for mobile-specific tasks), MobSF (static + dynamic analysis), Burp Suite + a CA installed on the device for HTTPS interception, jadx (Android decompiler), Hopper or Ghidra for iOS binaries. Most mobile pen-test methodology is "use Frida to bypass jailbreak / root detection, install your Burp CA, intercept all the API traffic, and find the bugs server-side."

The point

The mobile platform provides strong foundations — sandboxing, code signing, hardware-backed crypto. The application has to use them. Every M1–M10 above is a failure of the app, not the platform. The good mobile apps use Keychain/Keystore for credentials, enforce TLS with certificate pinning, validate every deep-link parameter, and treat the embedded WebView like the dangerous component it is.

If you can review a mobile app along the OWASP Mobile Top 10 dimensions, you can speak credibly with any mobile security team. Specialized mobile pen-testers go deeper — this is the foundation they build on.

References

Formatted in APA 7.

OWASP Foundation. (2024). OWASP mobile top 10. https://owasp.org/www-project-mobile-top-10/
OWASP Foundation. (n.d.). OWASP mobile application security testing guide (MASTG). https://mas.owasp.org/MASTG/
OWASP Foundation. (n.d.). OWASP mobile application security verification standard (MASVS). https://mas.owasp.org/MASVS/