Key Takeaways
- Defense in depth: security requires layers covering authentication, data storage, network, API, and code protection. A single vulnerability can expose all user data.
- Never store sensitive data unencrypted: use iOS Keychain and Android Keystore for credentials, tokens, and personal information.
- Certificate pinning prevents MITM attacks: validate the server's certificate against a known value, not just the certificate chain.
- Third-party libraries are attack vectors: audit dependencies regularly with OWASP Dependency-Check or Snyk. Remove unused libraries.
- Security testing is continuous: integrate static analysis, penetration testing, and dynamic analysis into your development process, not just at release.
Authentication and Session Security
| Practice | Implementation | Platform |
|---|---|---|
| Multi-factor auth | SMS, TOTP, push notification | Both |
| Biometric login | Face ID, Touch ID, fingerprint | iOS Keychain / Android BiometricPrompt |
| Token storage | Secure enclave / keystore | iOS Keychain / Android Keystore |
| OAuth 2.0 + PKCE | Authorization code flow with PKCE | Both |
| Session timeout | Auto-lock after inactivity | Both |
| Token refresh | Short-lived access + refresh token | Both |
Never store passwords locally, even encrypted. Never use API keys alone for user authentication. Never implement custom encryption; use platform-provided solutions (iOS Keychain, Android Keystore). These have hardware-backed security that custom solutions cannot match.
Data Storage and Encryption
Mobile devices are lost, stolen, and compromised. Every piece of sensitive data stored locally must be encrypted at rest:
| Data Type | Storage Method | Never Store In |
|---|---|---|
| Auth tokens | iOS Keychain / Android Keystore | SharedPreferences, UserDefaults |
| User credentials | Do not store (use tokens) | Any local storage |
| Personal data (PII) | Encrypted database (SQLCipher) | Plain SQLite, Realm unencrypted |
| API keys | Compiled + obfuscated | Strings.xml, Info.plist (plain text) |
| Session data | Encrypted shared prefs | Plain shared preferences |
| Cached images | Encrypted cache or in-memory | Unprotected disk cache |
Enable platform-level encryption: iOS encrypts data at rest by default when a passcode is set. Android offers full-disk encryption (FDE) and file-based encryption (FBE). Ensure your app properly uses NSFileProtectionComplete (iOS) and EncryptedSharedPreferences (Android).
Network Security and API Protection
- Enforce HTTPS everywhere: no exceptions. Use App Transport Security (iOS) and Network Security Config (Android) to prevent accidental HTTP connections.
- Certificate pinning: validate the server's certificate fingerprint, not just the chain. This prevents MITM attacks even on compromised networks. Use TrustKit (iOS) or OkHttp CertificatePinner (Android).
- API authentication: every request must carry a short-lived token. Validate tokens server-side. Never trust client-side validation alone.
- Rate limiting: implement both client-side (prevent excessive requests) and server-side (protect against abuse) rate limiting.
- Input sanitization: sanitize all user input, deep link parameters, push notification payloads, and inter-app communication data.
Pin against the intermediate certificate, not the leaf certificate. Leaf certificates rotate frequently (every 90 days with Let's Encrypt). Intermediate certificates rotate less often, reducing the risk of pinning failures and app lockouts.
Code Protection and Tamper Detection
| Technique | Purpose | Implementation |
|---|---|---|
| Code obfuscation | Prevent reverse engineering | ProGuard/R8 (Android), Swift compiler (iOS) |
| Root/jailbreak detection | Detect compromised devices | RootBeer (Android), IOSSecuritySuite |
| Debugger detection | Prevent runtime analysis | ptrace checks, timing analysis |
| Integrity checking | Detect modified APK/IPA | Signature verification at runtime |
| SSL unpinning detection | Detect Frida/Objection | Runtime hook detection |
No client-side protection is unbreakable. Obfuscation and tamper detection raise the bar but do not guarantee security. Critical business logic and validation must always live on the server. Client-side checks are defense-in-depth, not primary defenses.
Security Testing and Compliance
- Static analysis (SAST): scan code for vulnerabilities during development. Tools: SonarQube, Checkmarx, MobSF.
- Dynamic analysis (DAST): test the running app for vulnerabilities. Tools: OWASP ZAP, Burp Suite, Frida.
- Dependency scanning: check third-party libraries for known CVEs. Tools: Snyk, OWASP Dependency-Check, npm audit.
- Penetration testing: engage security professionals for manual testing quarterly or before major releases.
- Compliance verification: OWASP MASVS (Mobile Application Security Verification Standard) provides a comprehensive checklist.
| Test Type | Frequency | Cost |
|---|---|---|
| Automated SAST | Every commit (CI/CD) | $0-500/mo (tools) |
| Dependency scan | Weekly automated | $0-100/mo |
| Manual pen test | Quarterly or pre-release | $5K-20K per engagement |
| DAST automated | Monthly | $0-300/mo |
| Compliance audit | Annually | $10K-50K |
Review your app against the OWASP Mobile Top 10 annually. The current list includes: improper credential usage, inadequate supply chain security, insecure authentication, insufficient input validation, insecure communication, inadequate privacy controls, insufficient binary protections, security misconfiguration, insecure data storage, and insufficient cryptography.
Frequently Asked Questions
Related services from Verbsz Technologies
If this article is relevant to a project on your roadmap, these are the services our team typically delivers.