Mobile Application Security Testing for iOS and Android

A mobile application is distributed as a binary that runs in a hostile environment: the attacker's own device. This inverts a core assumption of web security.

The client is fully exposed

On the web, application logic lives on servers the attacker cannot read. A mobile app ships its logic to the endpoint. An attacker can pull the IPA or APK from a device, decompile it, extract hardcoded secrets, and study exactly how it authenticates and stores data. Any secret in the binary should be considered public.

The runtime can be manipulated

On jailbroken (iOS) or rooted (Android) devices, tools like Frida and Objection let testers and attackers hook functions at runtime — bypassing jailbreak detection, disabling certificate pinning, and altering return values. Controls that assume an untampered runtime will be defeated.

Data persists where you can see it

Apps cache tokens, personal data, and API responses in local databases, preferences files, and keychains. Misconfigured storage is one of the most frequently exploited mobile weaknesses.

Treat every client-side check — root detection, input validation, business rules — as a speed bump, not a wall. Authorization decisions must be re-verified server-side.

Because of these differences, mobile testing needs a purpose-built methodology rather than a repurposed web checklist.

Rather than improvising, mature mobile testing programs anchor to the OWASP Mobile Application Security project, which provides both a standard and a testing guide.

MASVS: what 'secure' means

The Mobile Application Security Verification Standard (MASVS) defines security requirements grouped into control categories such as storage, cryptography, authentication, network communication, platform interaction, code quality, and resilience against reverse engineering. It gives teams a shared definition of the target rather than a vague aspiration.

MASTG: how to test for it

The Mobile Application Security Testing Guide (MASTG) provides concrete test cases and techniques mapped to MASVS requirements, with platform-specific procedures for iOS and Android. It is the practical companion that turns requirements into repeatable tests.

Choosing a verification level

MASVS lets you scope rigour to risk. A casual utility app and a mobile banking app should not be held to the same bar. Higher-assurance apps add reverse-engineering resistance and anti-tampering requirements on top of the baseline controls.

Anchoring to MASVS/MASTG makes findings defensible and repeatable. A test result mapped to a published control is far more actionable than an ad-hoc observation.

GuardsArm structures mobile assessments around these standards so results integrate cleanly with broader compliance and penetration-testing programs.

Static Application Security Testing (SAST) examines the app without running it — inspecting source, bytecode, or the compiled binary for weaknesses.

What static analysis finds

• Hardcoded secrets: API keys, credentials, and encryption keys embedded in code or resources.
• Insecure configuration: debuggable builds, over-broad permissions, exported Android components, or disabled ATS on iOS.
• Weak cryptography: use of deprecated algorithms, ECB mode, or predictable initialization vectors.
• Dangerous API usage: unsafe deserialization, SQL built by string concatenation, or logging of sensitive data.

Tooling per platform

For Android, decompilers (jadx, apktool) reconstruct readable code from an APK, and automated scanners like MobSF surface manifest and code issues quickly. For iOS, class-dump and Hopper/Ghidra reveal Objective-C and Swift structure from the Mach-O binary. MobSF supports both platforms for a fast first pass.

Strengths and limits

Static analysis is fast, broad, and finds issues invisible at runtime — but it produces false positives and cannot confirm exploitability. A hardcoded string that looks like a key may be inert; a flagged flow may be unreachable.

Use static analysis to map the attack surface and generate hypotheses, then confirm the ones that matter with dynamic testing.

Dynamic Application Security Testing (DAST) runs the app on a device or emulator and observes real behaviour, while runtime instrumentation actively manipulates it.

Observing real behaviour

With the app running, testers inspect what it actually writes to disk, sends over the network, and exposes through inter-process communication. This confirms whether the issues static analysis suggested are real and reachable.

Runtime instrumentation with Frida

Frida injects a scripting engine into the running process, letting testers hook functions, read and modify arguments and return values, and dump decrypted data in memory. Objection builds on Frida to automate common tasks: bypassing jailbreak/root detection, disabling SSL pinning, and dumping the keychain.

Common runtime attacks to simulate

• Bypassing client-side controls such as root detection or biometric gates to confirm the server still enforces authorization.
• Tampering with logic — flipping a boolean that decides premium access, for example.
• Extracting secrets from memory after the app decrypts them.

If disabling a client-side check grants access to data or features, the real defect is missing server-side enforcement — not weak client detection.

Dynamic testing is where theoretical findings become demonstrated risk, which is exactly what a remediation team needs to prioritize.

Most mobile risk lives in the traffic between the app and its backend. Intercepting and analyzing that traffic is central to any assessment.

Setting up an intercepting proxy

Testers route device traffic through a proxy such as Burp Suite or mitmproxy, installing the proxy's CA certificate to read TLS-protected requests. This exposes the app's real API calls, authentication tokens, and any sensitive data in transit.

Certificate pinning and its bypass

Well-built apps use certificate pinning to reject any certificate but their own, defeating naive interception. Testers bypass pinning at runtime (via Frida/Objection) specifically to inspect the underlying API — which then reveals whether the backend independently enforces authorization and validation, or whether it trusted the pinned client to behave.

What to look for

• Sensitive data sent over plaintext HTTP or with TLS validation disabled.
• Authorization enforced only in the app, not re-checked at the API.
• Tokens that never expire, or that are reusable across accounts (IDOR).
• Excessive data returned by an endpoint that the app then filters client-side.

Pinning protects users against network attackers; it does not protect your backend against a tampered client. You need both pinning and server-side authorization.

The API behind a mobile app is often its weakest point, which is why mobile and API testing belong in the same engagement.

iOS and Android share concepts but differ in storage, IPC, and defaults — and each has recurring mistakes.

iOS

• Keychain misuse: storing secrets with weak accessibility attributes (e.g. accessible when unlocked but not requiring the device passcode) or leaving them in NSUserDefaults instead of the Keychain.
• App Transport Security exceptions: blanket ATS exceptions that re-enable insecure connections.
• Pasteboard and snapshot leakage: sensitive data left on the general pasteboard or captured in the app-switcher snapshot.

Android

• Exported components: activities, services, and broadcast receivers unintentionally exported and callable by other apps.
• Insecure storage: sensitive data in SharedPreferences, external storage, or SQLite without encryption.
• WebView risks: JavaScript bridges (addJavascriptInterface) and loading untrusted content that can reach native code.
• Backup and debuggable flags: allowBackup or debuggable left enabled in production.

Shared concerns

Both platforms suffer when apps embed secrets, log sensitive data, or trust the client. Biometric authentication on both should gate a server-verified action, never merely a local boolean.

Platform defaults change with each OS release. Test against the OS versions your real user base runs, not just the latest.

A thorough assessment applies the same MASVS controls but adapts every test to the platform's concrete mechanisms.

One-off tests find one-off bugs. Sustained mobile security comes from integrating testing into how apps are built and shipped.

Shift left without abandoning depth

• Run SAST and dependency scanning on every build in CI to catch regressions and vulnerable libraries early.
• Reserve manual, runtime-focused testing for meaningful releases, where human creativity finds the logic and authorization flaws scanners miss.

Manage the mobile supply chain

Third-party SDKs — analytics, ads, crash reporting — run inside your app with your permissions and can exfiltrate data. Inventory them, review what they collect, and track their vulnerabilities like any other dependency.

Test the whole system

Because mobile risk concentrates in the backend, pair mobile testing with API penetration testing. A finding like broken object-level authorization is only visible when you test the app and its API together.

Remediate and retest

Map every finding to a MASVS control, assign severity based on demonstrated impact, fix, and retest to confirm closure. Track recurring categories to drive secure-coding improvements.

Sustainable mobile security is a cycle: build securely, test each release, remediate, and feed lessons back into development.

GuardsArm delivers MASVS-aligned mobile assessments and pairs them with API and backend penetration testing so the full attack surface is covered, not just the app on the screen.