Mobile App Security Basics: Storage, TLS, and Jailbreak Signals

Quickstart

If you’re short on time, implement these in order. Each step reduces a common, real-world attack path with minimal complexity. The goal is not “unhackable” — it’s “hard enough that simple attacks fail, and risky conditions are handled safely.”

Overview

Mobile app security basics are easier to reason about if you split the world into three surfaces: data at rest (on device), data in transit (network), and device integrity (is the OS environment trustworthy?). This post covers a practical baseline for each:

You’ll also see how to think about trade-offs: certificate pinning reduces certain attacks but increases operational risk if you don’t plan rotations; root detection can reduce fraud but also harms legitimate users with custom ROMs; storing less data is often stronger than encrypting more data.

Core concepts

1) Secrets vs data: not everything deserves vault storage

The fastest way to improve mobile app security is to classify what you store: secrets (tokens/keys), sensitive user data (PII), and cacheable data (things you can re-fetch). Secrets should live in platform-protected storage; sensitive data should be minimized and protected; cacheable data should be treated as disposable.

2) Encryption is a system, not a function call

“We encrypt it” isn’t enough. Secure storage depends on where keys live, when they unlock, whether backups include data, and what happens when the device is compromised. A strong baseline uses the platform vault to keep key material out of files.

3) TLS: “works” is not the same as “secure”

A request over HTTPS can still be insecure if certificate validation is broken, if you allow cleartext fallbacks, or if you accept invalid certs “temporarily.” The baseline is: HTTPS only, default validation intact, and careful use of pinning.

4) Jailbreak/root detection: signal, not certainty

If the device is rooted/jailbroken, many protections can be bypassed. Integrity checks are still useful—especially for fraud prevention— but only when you design the response as a risk-based policy: “What do we allow, what do we step-up, and what do we block?”

Step-by-step

This section is a practical implementation path. You can adopt it incrementally: start with storage, then lock down TLS, then add integrity signals and a policy for what to do when risk is high.

Step 1 — Decide what you store (and what you should stop storing)

Before you code, reduce the amount of sensitive material your app holds. This is the “security win” most teams skip. For example: keep access tokens short-lived, store refresh tokens only when necessary, and avoid caching full API responses that contain PII when a partial cache would do.

Step 2 — Store secrets in Keychain (iOS) with restrictive defaults

On iOS, Keychain is the default place for credentials and tokens. The key choices are: accessibility (when the entry is available) and device binding (whether it can move via backup/restore). A common secure default for session tokens is “available when unlocked” and “this device only.”

import Foundation
import Security

enum KeychainError: Error { case unexpectedStatus(OSStatus) }

final class KeychainStore {
  private let service = "com.example.myapp"

  func saveToken(_ token: String, account: String = "session_token") throws {
    let data = Data(token.utf8)

    // Delete existing item first (idempotent save).
    let queryDelete: [String: Any] = [
      kSecClass as String: kSecClassGenericPassword,
      kSecAttrService as String: service,
      kSecAttrAccount as String: account
    ]
    SecItemDelete(queryDelete as CFDictionary)

    // Add a new item with restrictive accessibility:
    // - WhenUnlocked: only accessible while device is unlocked
    // - ThisDeviceOnly: not migrated via iTunes/iCloud backups to another device
    let queryAdd: [String: Any] = [
      kSecClass as String: kSecClassGenericPassword,
      kSecAttrService as String: service,
      kSecAttrAccount as String: account,
      kSecValueData as String: data,
      kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly
    ]

    let status = SecItemAdd(queryAdd as CFDictionary, nil)
    guard status == errSecSuccess else { throw KeychainError.unexpectedStatus(status) }
  }

  func loadToken(account: String = "session_token") throws -> String? {
    let query: [String: Any] = [
      kSecClass as String: kSecClassGenericPassword,
      kSecAttrService as String: service,
      kSecAttrAccount as String: account,
      kSecReturnData as String: true,
      kSecMatchLimit as String: kSecMatchLimitOne
    ]

    var item: CFTypeRef?
    let status = SecItemCopyMatching(query as CFDictionary, &item)

    if status == errSecItemNotFound { return nil }
    guard status == errSecSuccess else { throw KeychainError.unexpectedStatus(status) }

    guard let data = item as? Data else { return nil }
    return String(data: data, encoding: .utf8)
  }

  func deleteToken(account: String = "session_token") {
    let query: [String: Any] = [
      kSecClass as String: kSecClassGenericPassword,
      kSecAttrService as String: service,
      kSecAttrAccount as String: account
    ]
    SecItemDelete(query as CFDictionary)
  }
}

Step 3 — Lock down TLS and consider pinning for high-risk APIs (Android example)

The baseline is: use the OS defaults, rely on proper certificate validation, and ensure you never accept invalid certs. Pinning is optional: it can reduce some MITM risk, but it must be managed (rotation, backup pins, and failure behavior). If you pin, prefer pinning a public key hash (SPKI) and ship at least one backup pin for rotation.

import okhttp3.CertificatePinner
import okhttp3.OkHttpClient
import okhttp3.Request

// Pin the public key (SPKI) hash for your domain.
// Include at least one backup pin to allow certificate rotation.
val certificatePinner = CertificatePinner.Builder()
  .add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
  .add("api.example.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=") // backup
  .build()

val client = OkHttpClient.Builder()
  .certificatePinner(certificatePinner)
  .build()

fun fetchProfileJson(): String {
  val request = Request.Builder()
    .url("https://api.example.com/v1/profile")
    .get()
    .build()

  client.newCall(request).execute().use { response ->
    if (!response.isSuccessful) throw IllegalStateException("HTTP ${response.code}")
    return response.body?.string() ?: ""
  }
}

Step 4 — Verify your server TLS posture (quick sanity checks)

Mobile app TLS is only as strong as the server configuration. You don’t need a perfect TLS lab; you need to catch the obvious failures: weak protocol versions, wrong certificate chain, or unexpected redirects to HTTP. Run quick checks against your production endpoint during release reviews.

# Replace with your real host:
HOST="api.example.com"

# 1) Confirm the server completes a TLS 1.2 handshake (or newer).
openssl s_client -connect "${HOST}:443" -tls1_2 -servername "${HOST}" < /dev/null 2>/dev/null | grep -E "Protocol|Cipher|Verify return code"

# 2) Make sure there is no HTTP redirect or cleartext endpoint accidentally enabled.
curl -sS -o /dev/null -w "https_status=%{http_code} redirect_url=%{redirect_url}\n" "https://${HOST}/health"

# 3) If you use HSTS (web clients), ensure it’s present (not required for native apps, but good hygiene).
curl -sSI "https://${HOST}/" | grep -i "strict-transport-security" || echo "HSTS header not found"

Step 5 — Add jailbreak/root signals and decide policy

Integrity checks are not about “detecting every attacker.” They’re about avoiding the worst outcomes on compromised devices. Start with lightweight signals (debuggable flag, suspicious file paths, ability to write where you shouldn’t, hooking frameworks), and translate signals into a policy that matches your product risk.

Common mistakes

These are the patterns behind “we use HTTPS, so we’re secure” and “we encrypted it, so we’re done.” Most of them happen because a debug convenience accidentally becomes a production behavior.

FAQ

Should I use certificate pinning for every mobile app?

Not always. Pinning can reduce some man-in-the-middle risk, but it introduces operational risk (certificate rotation and outages). Use pinning for high-risk apps (financial, healthcare, admin tools) or high-value endpoints, and ship backup pins with a rotation plan. For many apps, correct default TLS validation + HTTPS-only + no cleartext fallback is already a strong baseline.

Where should I store access tokens and refresh tokens?

Store tokens in platform-protected storage: Keychain (iOS) and Keystore-backed encryption (Android). Prefer short-lived access tokens; store refresh tokens only if you need persistent sessions. If your app can function without a refresh token (e.g., re-auth on launch), that’s often safer.

Is “encrypting SharedPreferences/UserDefaults” enough?

It depends on where the encryption key lives. If the key is hardcoded or stored next to the ciphertext, it’s not a real boundary. The robust approach is: keep key material protected by Keychain/Keystore, then store ciphertext elsewhere. (Many platform libraries implement this pattern for you.)

What should my app do when it detects jailbreak/root?

Treat it as a risk signal. Common responses include: forcing re-authentication, disabling high-risk actions, reducing offline caching, or adding step-up verification. Blocking the entire app is usually a last resort unless your domain demands it.

Can I stop reverse engineering and hooking completely?

You can raise the cost, but you can’t guarantee prevention. Focus on reducing the impact: keep secrets out of code, validate critical actions on the server, use integrity signals, and ensure your app fails safely when the environment is compromised.

What’s the simplest way to avoid “oops, we shipped debug security”?

Add a release checklist: ban “trust all” networking code, block cleartext traffic, ensure logging is redacted, and run an end-to-end network test against production endpoints before signing builds. Small, strict checks beat big, rarely-used policies.

Cheatsheet

A scan-fast checklist for mobile app security basics: storage, TLS, and jailbreak signals.

Wrap-up

Mobile app security basics are mostly about strong defaults and removing footguns: store secrets safely, keep TLS validation intact, and treat jailbreak/root as a risk signal. You don’t need a perfect system to get real benefits—you need a consistent baseline and a habit of preventing regressions.

If you want to go deeper, check the related posts below for practical guidance on deep links, app architecture, and performance profiling— all of which can indirectly affect security through correctness and stability.

Related posts

• Deep Links That Work: Universal Links, App Links, and Edge Cases
• SwiftUI Layout: The Rules That Stop the ‘Why Is It Doing That?’
• iOS Architecture That Scales: MVVM, DI, and Feature Modules
• Make iOS Apps Smooth: Instruments Profiling Starter Guide
• Jetpack Compose: State, Effects, and UI That Doesn’t Jitter
• Android Studio Profilers: Fix the 90% of Slowdowns