Mobile Application Security
A mobile app runs in a hostile environment — on the user's device, which may be compromised, instrumented, and fully under an attacker's control. Two overarching rules follow: the final artifact (the built APK/IPA) can differ from what you wrote, and any verdict computed on the client will be forged by an attacker. Everything else is a consequence.
The main traps begin where the developer trusts the client: the manifest is merged from all dependencies, so one library re-enables cleartext; the screenshot cache leaks a screen holding a password when the app is backgrounded; OAuth in a WebView hands tokens to the hosting code; and a root/jailbreak check is hooked by a DBI tool like Frida and forced to return "clean". The breakdown is in the layers below.
Topic map
- Mobile app security basics — cleartext via dependency manifest merge, the screenshot cache, and OAuth in a WebView.
- Device tamper detection — why a client-side root/jailbreak check is unreliable and how to make it harder to bypass.
Common traps
| Mistake | Consequence |
|---|---|
| Checking only your own manifest, forgetting the dependency merge | A library re-enables cleartext and traffic goes over http |
Assuming the final APK is byte-identical to your source | The final config differs — you must inspect the built artifact |
| Not protecting a secret-entry screen from the screenshot cache | When backgrounded, a snapshot with the password leaks into the task preview |
Running OAuth through a WebView instead of the system browser | The hosting code sees the authorization tokens and cookies |
| Trusting the client verdict of a root/jailbreak check | A DBI tool hooks the check and returns "clean" |
| Throwing a visible exception on detection | You show the attacker the exact check location to bypass |
Interview relevance
The topic is asked to check your grasp of the "client vs server" trust boundary. A candidate who says "the final artifact and the client verdict cannot be treated as authoritative — critical decisions belong on the server" immediately separates from one who believes in an immutable manifest and a reliable local root check.
Typical checks:
- Why
cleartextmay flow despite yourusesCleartextTraffic=falseand where to look for the cause. - Why
OAuthin aWebViewis more dangerous than the system browser, and how a screen leaks via the screenshot cache. - Why client-side tamper detection is unreliable and how to harden it.
- How a DBI tool overrides a check (for example
evaluatePolicy) and bypasses biometrics.
Common wrong answer: "since my manifest forbids cleartext and the root check returned false, the device is clean". In fact the final manifest is merged from dependencies, and the boolean result of a local check is trivially forged by instrumentation.