Mobile Architecture Security

Mobile Security

A comprehensive reference for mobile application security: network transport protection, credential and secret storage, biometric authentication, app attestation, integrity checks, and the OWASP Mobile Top 10.

⏱ 13 min read

What it is

Mobile security encompasses the set of controls that protect a mobile application, its users, and the backend systems it communicates with from attack. Mobile apps face a threat model that differs from web applications: the app binary is distributed to untrusted devices, the network is potentially hostile (public WiFi, corporate proxies with TLS inspection), secrets embedded in the app can be extracted via static analysis, and the device itself may be compromised (jailbroken/rooted). Effective mobile security addresses all these vectors systematically rather than treating them as edge cases.

The OWASP Mobile Application Security Verification Standard (MASVS) and the OWASP Mobile Top 10 provide structured frameworks for identifying and mitigating mobile-specific risks. The controls range from transport security (certificate pinning, TLS 1.3) through data-at-rest protection (iOS Keychain, Android Keystore) to app integrity (Google Play Integrity API, Apple AppAttest).

Why it exists

Mobile apps regularly handle highly sensitive data: banking credentials, health records, authentication tokens, location history, and private communications. They do so on devices that are physically carried in pockets — devices that can be lost, stolen, or borrowed. The app binary is distributed publicly via app stores, giving attackers full access to reverse-engineer it. The network path is not controlled by the developer. This combination of sensitive data, distributed binary, and hostile environment makes mobile security a distinct and demanding discipline.

When to use

All mobile applications handling user authentication, personal data, payment information, or communications must implement the security controls described in this article. The OWASP MASVS L1 controls (baseline) apply to all apps; MASVS L2 (defence-in-depth) applies to apps handling financial, health, or otherwise sensitive data; MASVS-R (resilience) applies to apps facing sophisticated adversaries (banking, government, high-value gaming).

Typical architecture


CERTIFICATE PINNING
────────────────────
  Default TLS: validates cert against OS trust store
  → Vulnerable to: corporate MITM proxies, rogue CAs, NSS trust store attacks

  Certificate Pinning:
  App ships with expected certificate hash (SHA-256 of SubjectPublicKeyInfo)
  On each connection, app verifies server cert hash matches pinned value
  → Rejects connections to proxies, even with valid CA-signed certs

  Implementation:
  Android: OkHttp CertificatePinner / Android Network Security Config
  iOS: URLSession with URLAuthenticationChallengeSender / TrustKit
  NOTE: Pin the intermediate CA, not leaf cert (leaf rotates frequently)
  Provide a backup pin for rotation windows

SECURE STORAGE
────────────────
  NEVER store in:  SharedPreferences (Android, unencrypted)
                   UserDefaults (iOS, unencrypted)
                   SQLite without encryption
                   Plain files

  Android Keystore System:
  - Private keys stored in hardware-backed secure enclave
  - Never exported to app process memory
  - Keys can be bound to biometric authentication
  - EncryptedSharedPreferences (Jetpack Security Crypto)

  iOS Keychain:
  - Encrypted by iOS, keys protected by Secure Enclave
  - kSecAttrAccessibleWhenUnlockedThisDeviceOnly → not in iCloud backups
  - Can require biometric auth (kSecAccessControlBiometryCurrentSet)

BIOMETRIC AUTHENTICATION
─────────────────────────
  Android: BiometricPrompt API (fingerprint, face, iris)
           Class 3 biometrics required for Keystore-protected operations
  iOS:     LocalAuthentication framework (Touch ID, Face ID)
           LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics)

  CryptoObject binding: tie the biometric prompt to a Keystore key operation
  → The key is only usable if biometric auth succeeds in the same session
  → Resistant to biometric bypass via accessibility services

APP ATTESTATION
────────────────
  Google Play Integrity API:
  - App requests integrity token from Google Play
  - Backend verifies token with Google's server-side API
  - Token includes: MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY,
                    LICENSED (installed from Play), app hash
  → Detects: rooted devices, emulators, unofficial APK sideloads

  Apple App Attest / DeviceCheck:
  - App generates a key pair on the Secure Enclave
  - Apple's servers attest the key belongs to an unmodified app
  - Backend verifies assertion with Apple's attestation service
  → Detects: jailbroken devices, modified binaries

OWASP MOBILE TOP 10 (2024)
───────────────────────────
  M1: Improper Credential Usage (hardcoded creds, token in URL)
  M2: Inadequate Supply Chain Security (malicious 3rd party SDKs)
  M3: Insecure Authentication/Authorization
  M4: Insufficient Input/Output Validation
  M5: Insecure Communication (no cert pinning, HTTP allowed)
  M6: Inadequate Privacy Controls (over-requesting permissions)
  M7: Insufficient Binary Protections (no obfuscation, debuggable=true)
  M8: Security Misconfiguration (ADB backup enabled, debug logs in prod)
  M9: Insecure Data Storage (creds in SharedPreferences, logs with PII)
  M10: Insufficient Cryptography (MD5/SHA1, hardcoded IV, ECB mode)

Pros and cons

Pros

Certificate pinning prevents MITM attacks even from devices with compromised trust stores.
Hardware-backed key storage (Keystore/Keychain + Secure Enclave) makes key extraction from the device extremely difficult even with physical access.
App attestation allows the backend to validate it is talking to an unmodified app on an uncompromised device.
Biometric authentication bound to a Keystore key is resistant to PIN bypass and accessibility service attacks.

Cons

Certificate pinning can lock out legitimate users during certificate rotation if backup pins are not managed correctly; requires an operational certificate management process.
App attestation is probabilistic — a determined attacker with a custom Android build can pass Play Integrity checks on some devices.
Jailbreak/root detection creates friction for security researchers and users of legitimate custom ROMs; consider risk level before implementing hard blocks.
Overly aggressive security controls (e.g., refusing to run on any rooted device) drive users to unofficial APKs that have the controls removed.

Implementation notes

Certificate pinning rotation: Pinning the leaf certificate is fragile — leaf certs typically expire every 90 days. Pin the intermediate CA certificate's public key hash (SPKI hash) instead: it is stable for years and allows leaf cert rotation without an app update. Always include at least one backup pin (a pin for the next expected intermediate CA) to enable CA migration without a forced app update causing a service outage. Set a max-age on pins for Android Network Security Config to prevent pin persistence beyond the intended window.

Secrets in source code: Never commit API keys, client secrets, or backend URLs to source control. Use a secrets management tool (e.g., Android Secrets Gradle Plugin, iOS xcconfig with gitignored file) to inject secrets at build time. For secrets that must be on-device, use the Play Integrity API plus backend-issued, short-lived tokens rather than embedding long-lived API keys in the binary. Any secret in the APK/IPA can be extracted by decompiling — assume it is public knowledge.

Common failure modes

Credentials in SharedPreferences/UserDefaults: Auth tokens, passwords, and sensitive user data stored in unencrypted platform storage are readable by other apps on rooted devices and in full-device backups.
HTTP allowed in production: Failing to enforce HTTPS for all traffic (NSAppTransportSecurity exceptions on iOS, cleartext allowed on Android) exposes users on public WiFi to trivial MITM attacks.
Debug build in production: Shipping an app with android:debuggable=true or without ProGuard/R8 obfuscation makes reverse engineering trivial.
Token in URL: Placing auth tokens in query parameters causes them to appear in server access logs, browser history, and referrer headers — use Authorization header instead.
Missing certificate pinning bypass detection: If pinning can be trivially bypassed via Frida/objection, it provides false confidence; test pin bypass resistance regularly.

Decision checklist

Are all sensitive credentials and tokens stored in the platform keystore (Android Keystore / iOS Keychain)?
Is certificate pinning implemented with backup pins and a rotation procedure?
Is cleartext HTTP disallowed in network security configuration?
Is biometric authentication bound to a hardware-backed Keystore key operation?
Is app attestation (Play Integrity / App Attest) used for backend requests involving sensitive operations?
Is the app built with ProGuard/R8 (Android) or with full Swift optimisation (iOS) to resist reverse engineering?

Example use cases

Banking app: MASVS L2 + R controls: certificate pinning with SPKI hash, biometric-bound Keystore key for transaction signing, Play Integrity for every sensitive API call, Frida/root detection before app launch, jailbreak checks with graceful degradation (no full-blocking, but reduced features).
Healthcare app (HIPAA-relevant): All PHI stored in EncryptedSharedPreferences (Android) / Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly (iOS), device lock required before app opens, no PHI in application logs, no PHI in iCloud or Android Auto Backup.

Security Architecture — Broader security architecture patterns applicable across all system types.
Mobile API Design — API design decisions (versioning, transport security) that complement mobile client security.
Mobile Architecture Patterns — Proper separation of concerns (Clean Architecture) makes security controls easier to isolate and test.