Mobile Security
Mobile Application Security Testing: Protecting Tokens, APIs, and Local Data
How Android and iOS security assessments protect the app, device, network, and APIs behind it.
The mobile security model. A mobile app is not only its screens. It includes installed code, local files, secure storage, deep links, push notifications, device permissions, network traffic, and backend APIs. The assessment asks whether information and privileged actions remain protected when a device is lost, modified, shared, or connected to an untrusted network.
Static and dynamic testing. Static testing reviews the Android or iOS package for embedded keys, insecure settings, exported components, weak cryptography, debug features, and risky dependencies. Dynamic testing runs the app on a controlled device or emulator and observes login, storage, navigation, network calls, certificate handling, and runtime protections.
Key controls include secure storage, screen-capture rules, biometric fallback, session expiry, certificate pinning where appropriate, encrypted transport, root or jailbreak detection, inter-process communication, copy/paste handling, deep links, and notification privacy. The backend is tested too: the app must never be the final authority for a role, balance, subscription, or record owner.
A good finding distinguishes a theoretical weakness from a proven user-impact path. For example, an embedded key may be low impact when tightly restricted, while a cached session token on a shared device may permit account takeover. Recommendations include platform-specific guidance such as Keychain or Keystore usage, secret removal, deep-link constraints, and server-side enforcement.
Before release, repeat high-risk tests across supported OS versions and devices, review permissions and privacy disclosures, protect signing keys, and make security checks part of the build pipeline. Retesting confirms fixes before the next app-store submission.
Table of Contents
- The mobile attack surface
- Assessment areas
- Safe local-data example
- Risk and impact
- Remediation
The Mobile Attack Surface
A mobile assessment covers installed code, local files, secure storage, deep links, notifications, device permissions, network traffic, and the APIs behind the app. Security must hold when a device is lost, modified, shared, or connected to an untrusted network.
Mobile app ↔ device storage / OS services
↕
Network transport ↔ API / identity / business servicesAndroid and iOS Assessment Areas
Review authentication, session expiry, transport handling, local storage, logs, screenshots, clipboard exposure, deep links, permissions, exported components, update integrity, and API authorization.
The goal is not to declare every modified device safe. It is to keep sensitive data protected and ensure the server remains the final authority for every meaningful action.
Safe Local-Data Example
A test build may retain a session token in a debug log or insecure storage location. The secure pattern uses platform-protected storage, avoids logging secrets, and requires the server to validate token expiry and context for every request.
A user-interface lock alone is not a security boundary if a token can be extracted and reused elsewhere.
Risk and Business Impact
| Severity | Description |
|---|---|
| High | Exposed tokens can enable account takeover or API abuse. |
| High | Insecure local data can cause a privacy breach on a lost device. |
| Medium | Weak deep-link handling can enable unintended navigation or phishing-like flows. |
| Medium | API authorization flaws can expose data across users or tenants. |
Secure Release Controls
- Store sensitive credentials only in platform-protected storage.
- Use strong transport security and validate deep links and inter-app messages.
- Remove debug features, test endpoints, and verbose logs from production builds.
- Keep tokens short-lived and enforce authorization server-side.
- Test representative Android and iOS devices and supported operating-system versions.
Risk Rating
| Severity | Description |
|---|---|
| Critical | A weakness enables broad account compromise, privileged back-end actions, or high-impact data exposure. |
| High | Exposed credentials, insecure local data, or API flaws make account takeover or cross-user access practical. |
| Medium | A constrained device, deep-link, privacy, or workflow weakness affects a limited scenario. |
| Low | A minor implementation issue has limited practical impact but should be corrected before release. |
Mobile Security Checklist
- Secrets and tokens are not logged, embedded, or stored in plaintext.
- Sensitive storage uses platform-protected mechanisms.
- Deep links and inter-app communication validate input and destination.
- Every API request is authenticated and authorized server-side.
- Release controls remove debugging and test-only functionality.