Mobile Apps Can't Keep Secrets: API Security Patterns for the Device-Threat Landscape
Executive Summary
Mobile apps live and die by their APIs. But unlike web apps, mobile apps run on devices you don't control — and that changes the security model fundamentally.
Your mobile app is a public client. It cannot keep secrets. Attackers can decompile your code, intercept your traffic, replay your requests, and run your app on rooted or jailbroken devices. If your API security model assumes the app will behave, it's already broken.
This paper focuses on the device-threat layer — the API security challenges unique to mobile that general web API guidance doesn't address: token storage on untrusted devices, replay attacks from mobile clients, network-condition exploitation, device compromise scenarios, and the patterns that actually prevent silent data exposure from a mobile attack surface.
Why Mobile API Security Is a Different Problem
Web apps run in browsers you can patch. Mobile apps run on devices you can't.
On the web, the server controls the environment. You can rotate tokens via cookies, enforce CORS, and rely on the browser's same-origin policy. On mobile, the app binary lives on a device you'll never see, and attackers have full control of that device.
Here's what attackers can do with your mobile app that they can't easily do with a web app:
Decompile the APK/IPA to extract hardcoded keys, tokens, or logic
Run your app on a rooted (Android) or jailbroken (iOS) device with full filesystem access
Intercept and modify API traffic using proxy tools (Charles, Burp, mitmproxy)
Replay captured API requests with modified parameters
Automate API calls by scripting the app or calling endpoints directly
Extract tokens from insecure storage (SharedPreferences, UserDefaults, plain key-value stores)
The rule is simple: trust the server, not the app. Your API must enforce identity and authorization independently of what the client claims.
Threat 1: Token Theft via Device Compromise
On a compromised device, attackers can read your app's local storage. If your tokens are sitting in plaintext, they're gone.
The Problem
Many mobile apps store access or refresh tokens in insecure locations: Android SharedPreferences, iOS UserDefaults, or even plain text files. On a rooted or jailbroken device, these are trivially readable.
The Fix: Platform-Secure Storage
Use the platform's hardware-backed secure storage:
iOS: Keychain Services (hardware-backed on devices with Secure Enclave)
Android: Keystore (hardware-backed on devices with TEE/StrongBox)
Never store tokens in SharedPreferences, UserDefaults, or plaintext files
Never log tokens in crash reports or analytics events
Secure storage is necessary but not sufficient. A determined attacker with device access can still extract tokens from secure storage on a rooted device — which is why token lifecycle matters as much as storage.
Threat 2: Token Lifecycle on an Untrusted Device
If a token is stolen, the question is: how much damage can be done before it's useless?
Safe Baseline Pattern
Access token: short-lived (5–15 minutes). If stolen, it dies fast.
Refresh token: longer-lived, but used ONLY to mint new access tokens — never sent with API calls.
Rotation: refresh tokens rotate on every use. If a stolen token is replayed, reuse detection triggers revocation.
Revocation: server can invalidate all sessions on password change, device loss, or fraud signals.
Key practices:
Bind sessions to device signals where appropriate (device fingerprint, not perfect but adds friction for attackers)
Log refresh events and detect anomalies: impossible travel, rapid cycling, multiple concurrent refreshes
Require step-up authentication (MFA, biometric re-prompt) for sensitive actions like payment changes or PII export
Never embed long-lived API keys in the app binary — they will be extracted
Threat 3: API Replay and Parameter Manipulation
Mobile traffic is easy to intercept. An attacker on the same network, or with physical device access, can capture your API calls and replay them with modified parameters.
The Attack Pattern
An attacker captures a legitimate request: POST /api/orders with body {"productId": 42, "quantity": 1}. They replay it with {"productId": 42, "quantity": -1} or {"price": 0.01} to see if your API validates server-side.
Practical Mitigations
Rate limit per user, per IP, and per device fingerprint — not just per account
Use idempotency keys for write operations so replayed requests don't create duplicate charges or orders
Validate ALL input server-side — never trust prices, quantities, or permissions sent from the client
Detect burst behavior: if a user account suddenly makes 500 API calls in 2 minutes from a new device, flag it
Use challenge flows (CAPTCHA, device integrity attestation) for suspicious activity — but don't punish normal users
Threat 4: Broken Object Level Authorization (BOLA) from Mobile Clients
BOLA is the #1 API vulnerability — and mobile apps make it worse because they expose object IDs in traffic that's easy to intercept.
The Mobile-Specific Problem
A mobile app requests GET /api/invoices/12345. An attacker intercepts this, changes the ID to 12346, and replays. If your API only checks “is this user authenticated” — not “does this user own invoice 12346” — the attacker just read someone else's data.
The Fix
Every object access must verify: the object exists, the requester is allowed to access it, and the access is appropriate for the action (read vs write)
Query by both object ID and owner/tenant ID — never just object ID
Use UUIDs instead of sequential IDs (still must authorize, but prevents easy enumeration)
Test with explicit “user A tries user B's resource” cases — this is the test most teams skip
Threat 5: Network-Level Exploitation on Mobile
Mobile networks are hostile. Users connect to public WiFi, cellular networks with transparent proxies, and sometimes MITM certificates they installed without understanding.
This creates API security challenges web apps don't face:
Man-in-the-middle attacks on public WiFi — enforce certificate pinning for high-value APIs
Offline/retry behavior — if your app retries failed writes, ensure idempotency to prevent duplicate operations
Slow or interrupted connections — timeout handling must not leave partial state on the server
Network-level injection — some carrier proxies modify traffic. Validate content server-side, don't assume the request arrived intact
Certificate pinning note: pinning is powerful but operationally expensive. If you rotate certificates, a failed pin update can brick your app. Pin your backup certificate's public key alongside the primary, and have an emergency update path.
Threat 6: Over-Privileged Mobile Sessions
Mobile apps often request a single token at login and use it for everything — user actions, admin features, background sync. That convenience is a blast radius problem.
The Fix: Scope + Context
Scope tokens to the minimum needed: read vs write, user data vs admin actions, single resource vs global
Use separate tokens for background sync (low privilege) and interactive sessions (higher privilege)
Keep admin endpoints on a separate API surface with separate auth and MFA requirements
Require step-up auth (biometric re-prompt, MFA) before payments, PII export, or account changes
Threat 7: Device Integrity as a Risk Signal
Rooted and jailbroken devices aren't automatically malicious — many developers and power users root their devices. But they represent elevated risk.
Use device integrity as a risk signal, not a hard gate:
iOS: DeviceCheck and App Attest for hardware-backed attestation
Android: Play Integrity API (replaces SafetyNet)
Don't block rooted devices outright — use integrity signals to step up security: require MFA for sensitive actions, reduce token lifetimes, add challenge flows
Never rely on client-side root detection alone — it can be bypassed. Use it as one signal among many
Logging & Monitoring: Making Mobile API Abuse Detectable
If you can't see abuse, you can't stop it. Mobile-specific logging priorities:
Auth events: login, refresh, logout, failures — with device fingerprint and IP
Permission denials (403s) with reason codes — spikes indicate probing
Token refresh anomalies: reuse detection, impossible travel, rapid cycling
Sensitive actions: email change, password reset, payment method change, PII export
Rate limit triggers — patterns reveal automated abuse
Critical: don't log tokens, passwords, or PII in your logs. Correlate by request ID and user/session ID. Alert on spikes in 401/403, refresh reuse, and sensitive-action bursts from new devices.
Mobile-Specific Secure Release Checklist
Before shipping a mobile app with API access, confirm:
Tokens stored in Keychain (iOS) or Keystore (Android) — never plaintext
Access tokens short-lived (5–15 min); refresh tokens rotated with reuse detection
Every endpoint enforces resource-based authorization server-side (no client-trusted permissions)
No long-lived API keys embedded in the app binary
Idempotency keys on all write operations (mobile networks are flaky)
Rate limiting per user, per IP, and per device fingerprint
Step-up auth (MFA/biometric) for payments, PII export, and account changes
Device integrity signals collected and used as a risk multiplier (not a hard gate)
Certificate pinning considered for high-value APIs (with emergency rotation path)
Third-party API keys restricted by environment and scope
Pen test includes BOLA/IDOR test cases from a mobile attack surface (intercept + replay + modify)
No secrets in crash reports, analytics, or debug logs
Closing
Mobile API security isn't web API security with a different client. It's a fundamentally different threat model where the device is hostile territory, the network is unreliable, and your app binary is fully exposed to anyone who downloads it.
The practical path: treat the device as untrusted, enforce everything server-side, use platform-secure storage, rotate tokens aggressively, and make abuse visible through monitoring. Build these patterns in from the start and you reduce risk without slowing delivery.
Disclaimer
This white paper is published by BlueVioletApps LLC for informational and educational purposes only and does not constitute legal, compliance, or security consulting advice. Organizations should consult qualified security and legal professionals before implementing controls described herein. BlueVioletApps LLC is an independent software development firm and is not affiliated with, endorsed by, or officially connected to any federal agency, the Department of Defense, the Department of the Navy, NIST, GSA, or Google LLC. References to security frameworks and compliance standards are provided for general informational context only and are subject to change without notice.
Comments