Mobile Application Security
Mobile testing splits into client-side and server-side concerns. On the client, candidates must understand platform storage (Keychain/Keystore versus world-readable files and shared preferences), insecure logging, clipboard leakage, and screenshot/screen-recording exposure of sensitive screens. Know transport security: certificate pinning, and why bypassing pinning on a rooted or jailbroken device is straightforward with instrumentation frameworks. Understand that client-side controls (root detection, tamper checks, obfuscation) raise cost but are not security boundaries.
On the server side, the same API risks apply: broken object-level authorization, excessive data exposure in responses, and weak session/token handling. Mobile clients are untrusted; anything shipped in the app-API keys, endpoints, logic-is discoverable. Questions often test whether a finding is client-only or has server impact, and whether data at rest is protected by OS facilities or custom crypto (custom crypto is usually the weaker choice).
Traps: assuming jailbreak detection prevents reverse engineering; treating a hardcoded API key as harmless when it grants privileged access; and confusing certificate pinning with encryption. Also watch for questions about deep links and exported components allowing unintended invocation of app functionality.
Worked example: an app stores an auth token in plaintext shared preferences on Android, readable by other apps on a rooted device or via backup. The finding is insecure data storage. Remediation is using Keystore-backed encrypted storage and disabling backup of sensitive files. Rule of thumb: assume the device and the app binary are attacker-controlled-design so that only server-side checks enforce authorization and sensitive data is protected by platform keystores.