Mobile app security testing covers the app on the device and the backend API it calls, structured by the OWASP MASVS. Work through six areas: insecure storage (tokens/PII/keys in plaintext), weak crypto, network security & certificate pinning, platform interaction (Android exported components/IPC, iOS Keychain/URL schemes), code protection (hardcoded secrets, reverse engineering, tamper/root detection), and — most important — the backend API, where the real data and business logic live. iOS and Android share the concepts but differ in mechanics. Combine static (unpack the package), dynamic (run on device, intercept traffic) and API testing. Full checklist below; for scoped delivery see our mobile penetration testing service.
// 01 Why mobile testing is its own discipline
A web app runs on a server you control; a mobile app runs on hardware the attacker owns. They can pull the app package apart, read its files, hook its functions at runtime with tools like Frida, and man-in-the-middle its traffic. That flips the threat model: you cannot assume anything on the device is secret or trustworthy. Testing therefore blends static analysis (decompiling and inspecting the IPA/APK), dynamic analysis (running the app on a jailbroken/rooted device or emulator and observing its behaviour), and API testing of the backend. The OWASP MASVS gives the control framework and the MASTG the concrete techniques — the structure the rest of this checklist follows.
// 02 Storage & cryptography
The first question on any device: what did the app leave lying around? Inspect local storage for sensitive data written in the clear — auth tokens, personal data or keys in shared preferences, plist files, unprotected SQLite databases, logs, or the app's cache. On iOS, sensitive values belong in the Keychain with an appropriate data-protection class, not in UserDefaults; on Android, check for world-readable files and unencrypted databases. Then test cryptography: weak or deprecated algorithms, hardcoded or predictable keys, ECB mode, custom crypto, and keys stored alongside the data they protect. The recurring finding is simple and serious — secrets persisted to a device the attacker can read at leisure.
// 03 Network security & certificate pinning
All app-to-server traffic must be encrypted and validated. Confirm TLS everywhere (no cleartext HTTP fallbacks), that the app rejects invalid or self-signed certificates, and check certificate pinning: is it implemented, and can it be bypassed? Pinning is a valuable control, but a test should attempt to defeat it — because if a tester can strip it with a runtime hook, so can an attacker, and the “encrypted” channel becomes fully readable. We cover the practical bypass techniques in bypassing certificate pinning on iOS. Once traffic is visible, the whole API surface is exposed — which is why network testing is the bridge to the most important area of all, the backend.
// 04 Platform interaction & code protection
Android IPC
Exported activities, services, broadcast receivers and content providers; intent handling and deep links.
iOS surface
Keychain usage, data-protection classes, URL schemes, universal links and pasteboard leakage.
Hardcoded secrets
API keys, credentials and endpoints baked into the binary — extractable by anyone.
Tamper & reverse
Reverse-engineering resistance, root/jailbreak detection, anti-tamper — useful but never a substitute for server-side controls.
A note on code protection: obfuscation, root detection and anti-tamper raise the cost for an attacker, but they are speed bumps, not walls. Never let them substitute for real controls on the server. A hardcoded API key is a finding no matter how well the binary is obfuscated.
// 05 The backend API — where the risk really is
Here's the point most mobile tests underweight: the app is just a client; the data lives in the API. An attacker doesn't need to defeat your app — they intercept its traffic, learn the API, and call it directly, bypassing every client-side control. So the highest-impact mobile findings are almost always server-side: broken object-level authorisation (one user reading another's records via a manipulated ID), missing function-level checks, weak session handling, and business-logic flaws. Testing the app without testing the API it calls misses most of the real risk. Treat the backend as a first-class part of the engagement — the same rigour as our API penetration testing, guided by the OWASP API Security Top 10.
// 06 iOS vs Android: same checklist, different mechanics
The six control areas apply to both platforms, but the techniques diverge. Android is more open: the file system is more accessible, and exported components, intents and deep links are a rich attack surface, so IPC testing looms large. iOS is more locked down: the sandbox is tighter, so testing centres on the Keychain, data-protection classes, URL schemes and pasteboard behaviour. Storage, crypto, network and code-protection checks map across both, but a competent test treats each platform on its own terms with the right tooling rather than assuming parity. If you ship both, budget to test both — a clean Android result doesn't certify the iOS build.
// 07 Frequently asked questions
What is mobile app security testing?
It assesses an iOS or Android app across storage, cryptography, network communication, platform interaction, code protection and backend APIs — combining static analysis of the package, dynamic analysis of the running app, and API testing. The reference standard is OWASP MASVS with its companion testing guide MASTG.
What are the most common mobile vulnerabilities?
Insecure local storage of tokens, PII or keys; weak or misused crypto; missing or bypassable certificate pinning; insecure IPC and exported components on Android; hardcoded secrets and API keys; and weak server-side API controls. Many mobile findings ultimately trace back to the backend API the app calls.
Is the backend API part of a mobile pentest?
It should be, and it's usually where the highest-impact findings are. The app is a client; the data and business logic sit in the API. An attacker can bypass the app and hit the API directly, so testing must include server-side authorisation, object-level access control and business logic — not just the app binary.
What's the difference between iOS and Android testing?
The controls are the same conceptually but the mechanics differ. Android focuses on exported components, intents and the open file system; iOS on the Keychain, data-protection classes, URL schemes and the tighter sandbox. Storage, crypto, network and code-protection checks apply to both with different techniques, so a competent test covers each platform on its own terms.
// 08 Related reading
- Mobile application penetration testing — scoped delivery of this checklist.
- Bypassing certificate pinning on iOS and the session management checklist.
- OWASP API Security Top 10 and API penetration testing — the backend behind the app.