Platform Security Fundamentals
Secure Credential Storage iOS Keychain provides encrypted storage for credentials with hardware-backed encryption on devices with Secure Enclave. Keychain items should be marked as accessible only when device is unlocked. Android Keystore provides hardware-backed key storage on devices with Trusted Execution Environment or Secure Element. Keystore keys cannot be extracted from hardware. Hardware-backed storage should be used when available, with software fallback for older devices. Hardware backing provides strong protection against extraction. Biometric authentication should protect Keychain and Keystore access for high-value operations. Biometrics provide user-friendly authentication. Transport Security App Transport Security (ATS) on iOS enforces TLS 1.2+ with forward secrecy by default. ATS exceptions should be minimized and justified. Network Security Configuration on Android enforces TLS requirements and certificate pinning. Configuration should be declared in XML. Certificate pinning validates that server certificates match expected certificates or public keys. Pinning prevents man-in-the-middle attacks from compromised CAs. Pin rotation strategies should enable certificate updates without app updates. Backup pins and pin expiration enable graceful rotation. Jailbreak and Root Detection Jailbreak and root detection provides weak signal of compromised device but should never be security boundary. Detection can be bypassed by determined attackers. Detection results should inform risk-based decisions including additional authentication or reduced functionality. Detection should not prevent app from functioning. Server-side risk scoring should incorporate device integrity signals with other risk factors. Client-reported signals cannot be trusted.Data at Rest Security
Minimize On-Device Secrets High-value secrets including API keys and encryption keys should not be stored on devices. Server-side secrets should be accessed through authenticated APIs. Short-lived tokens with narrow scope should be used instead of long-lived credentials. Token expiration limits impact of token theft. Refresh tokens enable long-lived sessions without storing long-lived credentials. Refresh tokens should be rotated regularly. Application Data Encryption Application data should be encrypted using platform APIs including iOS Data Protection and Android File-Based Encryption. Platform encryption is transparent to applications. Sensitive data should be marked with appropriate protection class. iOS protection classes control when data is accessible. Custom encryption should use platform cryptographic APIs rather than custom implementations. Custom crypto implementations are error-prone. Backup Protection Sensitive data should be excluded from backups using no-backup flags. Backups may be stored in less secure locations. Backup encryption should be verified. Unencrypted backups expose sensitive data. Data wipe on device compromise signals including multiple failed authentication attempts provides defense-in-depth. Wipe should be user-configurable.Authentication and Session Management
OAuth and System Browsers OAuth flows should use system browsers including ASWebAuthenticationSession on iOS and Custom Tabs on Android. System browsers provide better security than embedded webviews. Embedded webviews enable phishing and credential theft. Webviews should be avoided for authentication. PKCE (Proof Key for Code Exchange) protects authorization code flow for public clients. PKCE prevents authorization code interception. Token Management Access tokens should have short lifetime (minutes to hours). Short lifetime limits impact of token theft. Refresh tokens should be rotated on each use. Rotation enables detection of token theft. Token binding to device using device fingerprints or hardware-backed keys prevents token replay on different devices. Binding should be transparent to users. Replay Protection Nonce values prevent replay of authentication requests. Nonces should be single-use and time-limited. One-time codes for high-value operations prevent replay. Codes should expire quickly. Anti-CSRF tokens protect webview-based flows. CSRF protection should be server-enforced.Code and Runtime Hardening
Obfuscation Limitations Code obfuscation increases reverse engineering cost but does not prevent it. Obfuscation should not be relied upon as security control. Server-side validation should enforce all security policies. Client-side checks can be bypassed. Security through obscurity is not security. Assume that attackers can reverse engineer all client code. Runtime Integrity Runtime integrity checks detect tampering and debugging. Checks should degrade gracefully rather than crash. Signed builds with code signing certificates prove app authenticity. Signature verification should be platform-enforced. Secure supply chain practices including dependency scanning and build provenance prevent supply chain attacks. Dynamic Code Loading Dynamic code loading including JavaScript bridges and plugin systems increases attack surface. Dynamic loading should be minimized. Code signature verification should apply to all loaded code. Unsigned code should be rejected. Deep link handlers should validate all inputs and implement authorization checks. Deep links are common attack vector.OWASP MASVS and Security Testing
Mobile Application Security Verification Standard OWASP MASVS provides comprehensive mobile security requirements across three levels. Level 1 provides baseline security for all apps. MASVS categories include architecture, data storage, cryptography, authentication, network communication, platform interaction, code quality, and resilience. MASVS adoption should be risk-based with higher levels for apps handling sensitive data. Requirements should be incorporated into development standards. Mobile Security Testing Guide MASTG (Mobile Security Testing Guide) provides testing procedures for MASVS requirements. Testing should be automated where possible. Static analysis tools including MobSF detect common vulnerabilities in source code and compiled binaries. Static analysis should run in CI/CD pipelines. Dynamic analysis using Frida scripts enables runtime testing and instrumentation. Dynamic analysis should test authentication, authorization, and data protection. API Security Testing Mobile API endpoints should be tested for abuse including authentication bypass, authorization flaws, and rate limiting. Mobile channels should not be trusted. API testing should use same test corpus as web testing. Mobile-specific attack vectors should be added. Rate limiting and abuse detection should apply to mobile API endpoints. Mobile apps can be automated for abuse.CI/CD Integration
Security Scanning Dependency scanning identifies vulnerable libraries. Scanning should block builds with critical vulnerabilities. SAST (Static Application Security Testing) detects code-level vulnerabilities. SAST should be tuned to reduce false positives. Binary analysis scans compiled applications for security issues. Binary scanning should occur before release. Findings Management Security findings should be tracked in issue tracking systems. Findings should have SLAs for remediation. Vulnerability severity should drive remediation priority. Critical vulnerabilities should be fixed immediately. Release Signing Release builds should be signed with protected signing keys. Signing keys should be stored in HSMs or cloud key management. Signing should be automated in CI/CD pipelines. Manual signing creates operational risk.Conclusion
Mobile application security requires assuming device compromise and implementing server-side enforcement of security controls. Security engineers design mobile security architectures that minimize on-device secrets, use platform security features, and degrade gracefully when client protections are bypassed. Success requires treating mobile devices as hostile environments and implementing defense-in-depth with server-side validation. Organizations that invest in mobile security fundamentals build applications that resist attacks even when running on compromised devices.References
- OWASP Mobile Application Security Verification Standard (MASVS)
- OWASP Mobile Security Testing Guide (MASTG)
- Apple Platform Security Guide
- Android Security Documentation
- Mobile Security Framework (MobSF)