Mobile App Security: iOS and Android Protection Guide
Mobile applications process sensitive personal data — financial transactions, health records, private communications, and biometric identifiers — making them prime targets for attackers. The 2025 Verizon Mobile Security Index found that 43% of organizations experienced a mobile-related security incident, with data exfiltration via malicious apps increasing 87% year-over-year. This guide covers the iOS and Android platform security models, the OWASP Mobile Top 10, practical app hardening techniques, and mobile penetration testing methodology.
Platform Security Models
iOS and iPadOS Security
iOS employs a layered security architecture rooted in the Secure Enclave — a dedicated AES-256 crypto engine isolated from the main processor. The Secure Boot Chain verifies each stage of boot (Boot ROM → iBoot → kernel) through signed cryptographic digests; a chain break renders the device unbootable. iOS 17+ introduced Lockdown Mode, an extreme protection state that blocks most web technologies (JIT, complex JavaScript), attachment types, and incoming FaceTime calls.
App sandboxing prevents each application from accessing other apps’ data without explicit entitlement. The App Store review process, while imperfect (NIST IR 8399 documented bypass techniques), provides baseline malware screening. Keychain data is encrypted with device-specific keys derived from the user’s passcode via PBKDF2.
Android Security
Android’s security model centers on the Linux kernel’s discretionary access control (DAC) plus SELinux mandatory access control (MAC). Each app runs as a unique Linux user ID with a dedicated sandbox directory. Android 14+ introduced enhanced credential management with passkey-first authentication (using FIDO2/WebAuthn) and a permission manager that grants one-time permissions (camera, microphone, location) active only while the app is in the foreground.
Google Play Protect scans 200+ billion apps daily for malware. However, side-loaded apps bypass Play Protect, and Android’s fragmented OS version adoption means many devices run outdated security patches — 31% of Android devices were still on Android 12 or earlier as of early 2025 per Google’s distribution dashboard, missing critical kernel protections added in Android 13+.
OWASP Mobile Top 10
The OWASP Mobile Top 10 (2024 edition) provides the definitive taxonomy of mobile security risks.
M1 — Improper Platform Usage
Misuse of platform APIs and security controls — for example, storing credentials in SharedPreferences (Android) or NSUserDefaults (iOS) without encryption. Mitigation: use EncryptedSharedPreferences (Android) or the iOS Keychain for all secrets.
M2 — Insecure Data Storage
Mobile devices are frequently lost or stolen. Data stored without encryption — SQLite databases, Realm files, Core Data stores, log files, cache directories — exposes sensitive information. A 2024 forensic analysis of 25 popular finance apps found that 32% stored access tokens in plaintext within sandbox directories. Mitigation: Use SQLCipher for database encryption, store tokens in Keychain/Keystore, and apply NSFileProtectionComplete (iOS) or Android file-based encryption.
M3 — Insecure Communication
Mobile apps communicating over unencrypted channels expose data to interception on public Wi-Fi. Even with HTTPS, certificate validation must be strict: do NOT allow all certificates (NSAllowsArbitraryLoads on iOS, trusting user CAs on Android). Certificate pinning (using TrustKit or OkHttp’s CertificatePinner) prevents MITM attacks even if a CA is compromised.
M4 — Insecure Authentication
Weak session management — long-lived tokens, no token rotation, tokens stored without additional device verification — enables session hijacking. Implement OAuth 2.0 with PKCE, short-lived access tokens (15-60 minutes), refresh token rotation, and biometric step-up for sensitive operations. AppAuth (iOS/Android) provides a standards-compliant OAuth 2.0 client.
M5 — Insufficient Cryptography
Custom cryptographic implementations are almost always broken. Use platform-provided cryptography: CommonCrypto (iOS) and Android Jetpack Security (AndroidCrypt). Never implement your own padding, key derivation, or encryption algorithms.
M6 — Insecure Authorization
Server-side authorization failures: APIs that trust client-supplied user IDs, role information, or resource identifiers without server-side verification. All authorization decisions must be enforced server-side — client-side checks are trivially bypassed on jailbroken/rooted devices.
M7 — Client Code Quality
Buffer overflows, format string vulnerabilities, memory corruption in native code (C/C++ via JNI/NDK). Static analysis tools (QARK for Android, MobSF for both platforms) identify code quality issues.
M8 — Code Tampering
Mobile apps run in untrusted environments. Attackers can repackage, resign, and redistribute modified APKs (Android) or decrypt and modify IPA bundles (iOS). Integrity checks — verifying code signatures at runtime, using Google Play Integrity API or iOS DeviceCheck — detect tampering.
M9 — Reverse Engineering
Mobile apps are susceptible to decompilation: jadx (Android decompiler) and Hopper/Ghidra (iOS disassembler) can reconstruct source logic. Obfuscation tools (ProGuard/R8 for Android, LLVM obfuscation for iOS) make reverse engineering more expensive. However, obfuscation raises security through obscurity — it should supplement, not replace, strong cryptographic and server-side controls.
M10 — Extraneous Functionality
Test endpoints, debug menus, staging API keys, or hidden features accidentally included in release builds. Use build configuration flavors and preprocessor flags to strip debug code from production builds.
App Hardening Techniques
Runtime Application Self-Protection (RASP)
RASP libraries embed security monitoring into the app runtime. They detect: debugging (debugger attached detection on both platforms), jailbreak/root detection (checking for Cydia Substrate, Magisk, SuperSU), Frida detection (checking for Frida server ports), certificate pinning bypass detection, and environment integrity (emulator detection). However, RASP is not a silver bullet — determined attackers can bypass individual checks.
Secure Enclave and Biometrics
iOS LocalAuthentication (LAContext) and Android BiometricPrompt (BiometricManager) use platform-level biometric authentication (Face ID, Touch ID, fingerprint scanner). Biometric authentication protects secrets stored in the Secure Enclave (iOS) or TEE (Android). Note that Android’s biometric compatibility mode falls back to device PIN/pattern, which is a weaker factor.
TLS and Network Security
Configure network security: Android’s network_security_config.xml pins certificates; iOS’s Info.plist sets NSAppTransportSecurity to require HTTPS. Implement certificate transparency checking (using TrustKit or static CT logs). Server certificate validation must include: issuer validation, expiration check, revocation status (OCSP stapling), and hostname verification.
Mobile Penetration Testing
Mobile pentesting requires specialized tools and methodology.
Setup
A testing lab requires: a jailbroken iPhone (checkra1n for iOS 14-16, palera1n for iOS 16+, Dopamine for iOS 15-16) or rooted Android device (Magisk), Burp Suite with mobile CA certificate installed for HTTPS interception, objection (Frida wrapper for runtime analysis), and Frida for dynamic instrumentation.
Common Testing Areas
Traffic analysis: intercept all API calls, verify TLS pinning, check for hardcoded secrets in request bodies. Storage analysis: examine Keychain/Keystore, SharedPreferences, SQLite databases, Realm files, Core Data stores, and NSUserDefaults using objection’s android extract or ios dump. Binary analysis: decompile with jadx or Hopper, look for hardcoded API keys, AWS access keys, OAuth client secrets, and internal URLs.
Mobile Supply Chain Security
Mobile applications inherit risk from their supply chain — third-party SDKs, libraries, and dependencies.
Third-Party SDK Risks
Mobile SDKs are among the most dangerous supply chain vectors because they run with the host app’s permissions. In 2024, researchers discovered that 18 popular Android SDKs (including an analytics SDK used in 5,000+ apps) were exfiltrating user data to third-party servers without disclosure. The XcodeSpy attack (2021) embedded surveillance capabilities through a malicious Xcode project in open-source Swift libraries. The OWASP Mobile Top 10 M8 (Code Tampering) and M9 (Reverse Engineering) risks are amplified when SDK code operates at the application thread level.
SDK vetting should include: network traffic analysis (observe what domains the SDK contacts), permission audit (does the SDK require more permissions than functionally necessary?), and obfuscation review (is the SDK intentionally hiding behavior?). Use Gradle dependency locking (Android) or SPM dependency resolution (iOS) to pin SDK versions and prevent supply chain updates from introducing malicious code.
App Store Security Comparison
Google Play Protect scans sideloaded apps and Play Store submissions with near real-time analysis, detecting 1.5 million+ malicious apps annually. Apple’s App Store review uses automated scanning combined with manual review, though the 2023 Pegasus spyware infiltration demonstrated that sophisticated malware can bypass both. Both platforms now require: privacy nutrition labels (privacy manifests on iOS, Data Safety section on Play), minimum SDK versions (iOS 17 minimum for new apps, API 34+ for Android), and attestation APIs (DeviceCheck on iOS, Play Integrity API on Android).
FAQ
What is the difference between app sandboxing on iOS and Android? iOS uses a mandatory sandbox where apps cannot access each other’s data without explicit entitlements and user consent. Android uses UID-based sandboxing with SELinux MAC for finer-grained process isolation.
Should I use root/jailbreak detection? It raises the bar for casual attackers but is bypassable. Combine with strong server-side controls and RASP for defense in depth.
How do I securely store an API token on mobile? Use the iOS Keychain (kSecClassGenericPassword) or Android EncryptedSharedPreferences with master keys stored in the Android Keystore. Never store tokens in SharedPreferences, NSUserDefaults, or as files without encryption.
What is certificate pinning? Embedding the expected server certificate or public key hash in the app binary so the app only accepts connections from servers presenting that specific certificate. This prevents MITM attacks even if a CA is compromised.
How often should I update my mobile app’s dependencies? Review and update all third-party libraries monthly. Use Dependabot or Renovate for automated dependency PRs. Prioritize updates for networking, cryptography, and authentication libraries.
For core security concepts, read our Security Guide. Secure your mobile APIs with OAuth 2.0 and JWT Guide. For cloud-backed mobile apps, see Cloud Security Guide.