Mobile Application Security Testing: The App, the Device and the API

Securing a mobile application presents fundamentally different engineering challenges from securing a traditional web application. In web architecture, server-side code executes within an isolated, trusted cloud environment under your direct control. In mobile architecture, the compiled client package (APK/AAB for Android, IPA for iOS) executes entirely on hardware controlled by an untrusted user.

An adversary who downloads your application from the Google Play Store or Apple App Store possesses unrestricted physical, administrative, and runtime access to the device. The attacker can decompile bytecode into readable source code, attach dynamic debuggers, dump volatile device memory, hook native operating system functions, and intercept all encrypted network communications.

To evaluate mobile security comprehensively, testing must align with the OWASP Mobile Application Security Verification Standard (MASVS v2.0) and the Mobile Application Security Testing Guide (MASTG). A rigorous assessment evaluates three interconnected frontiers: the static client binary, the local device runtime environment, and the backend cloud API.

Because Android applications are compiled to Dalvik Executable (DEX) bytecode and iOS applications to ARM machine binaries, static analysis begins with reverse engineering:

• Bytecode Decompilation: Assessors use tools such as JADX, apktool, Ghidra, and Hopper to decompile the application package back into Java/Kotlin or decompiled C/Swift pseudo-code. This reveals internal class architectures, business logic routines, and API endpoints.

• Hardcoded Secrets and Cryptographic Keys: A frequent finding is the inclusion of sensitive configuration secrets—such as AWS access keys, private encryption certificates, JWT signing secrets, and third-party API credentials—embedded directly within source code or asset files.

• Third-Party SDK Vulnerabilities: Mobile applications routinely integrate dozens of tracking, advertising, and analytics SDKs. Each SDK introduces additional attack surface, potentially leaking user PII, executing unverified dynamic code, or bypassing platform permission boundaries.

Once installed, mobile applications store session tokens, user preferences, cached data, and local databases on the device filesystem. Common vulnerabilities include:

• Insecure SharedPreferences and Local Databases: Storing authentication tokens, credit card fragments, or personal data in unencrypted SQLite databases or world-readable XML preference files. On rooted or jailbroken devices, or through automated backup utilities (such as Android ADB backup), this data can be extracted directly.

• Hardware-Backed Cryptographic Storage: High-security applications must store cryptographic keys exclusively within hardware-backed security modules: the Android Keystore (backed by the Trusted Execution Environment or StrongBox) or the iOS Keychain (backed by the Secure Enclave). Assessors verify whether cryptographic keys are protected by hardware or improperly derived in software RAM.

Mobile operating systems isolate applications through process sandboxing, requiring components to communicate via formal Inter-Process Communication (IPC) mechanisms:

• Exported Android Components: In Android, Activities, Services, Broadcast Receivers, and Content Providers marked with exported flags in the application manifest can be invoked by any other application installed on the same phone. If an exported component fails to validate caller permissions, a rogue third-party app can trigger unauthorized background actions or extract database records.

• Deep Links and Custom URL Schemes: Custom URL schemes that fail to validate input parameters can be intercepted by malicious apps registered to the same scheme or manipulated via mobile browser redirects.

• Vulnerable WebViews: When applications embed WebViews configured to allow unrestricted JavaScript execution and bridge native platform methods to web pages, an attacker capable of injecting web content can execute native operating system code on the user’s mobile device.

During runtime testing, offensive engineers use dynamic binary instrumentation frameworks—principally Frida and Objection—to inject logic directly into running process memory on jailbroken iOS or rooted Android devices. Rather than modifying the application package on disk, dynamic instrumentation operates in RAM while the app executes:

• Certificate Pinning Bypasses: Applications frequently implement SSL/TLS certificate pinning to prevent network eavesdropping. Assessors use dynamic hooks to intercept the operating system’s trust validation functions in memory, replacing them with stubs that accept any certificate. This immediately allows the tester to route encrypted traffic through an intercepting proxy and audit the underlying backend API.

• Root and Jailbreak Detection Evasion: Assessors hook low-level filesystem query functions to conceal the presence of administrative binaries (such as `su`) and test keys, allowing the application to execute normally on compromised devices.

• Biometric Authentication Circumvention: By hooking biometric callback handlers in volatile memory, an assessor can signal successful authentication to the application without presenting valid fingerprint or facial recognition credentials.

These runtime techniques demonstrate why client-side protections must be viewed solely as defense-in-depth hurdles rather than authoritative barriers. Any logic executing on a user’s device can ultimately be subverted by a determined adversary with physical access.

A fundamental principle of mobile application security is that the client application must never be trusted. Code obfuscation and anti-tamper protections slow attackers down, but they cannot prevent a determined adversary from reverse engineering and instrumenting the app.

Every authorization boundary, business logic rule, input validation check, and transaction verification must be enforced strictly on the backend API. A mobile application backend must treat all incoming HTTP requests as potentially malicious and crafted by an adversary, regardless of what client headers or tokens are presented.

Relying on code obfuscation or root detection as primary security controls is an architectural anti-pattern. If an application’s security model depends on an attacker being unable to inspect client logic, the system is already compromised. Client protections introduce friction, but authoritative authorization must always be enforced on the backend cloud API.