Mobile Application Security Fundamentals

Why Mobile Is a Distinct Attack Surface

Mobile apps run on devices the organization doesn't control, store sensitive data outside the normal network perimeter, and communicate through platform-specific mechanisms (intents, deep links) that have no direct web equivalent. Everything from Web Security and Ethical Hacking still matters once a mobile app talks to a backend API — this lesson covers what's different about the app itself.

Sandboxing: Android vs iOS

Both platforms isolate apps from each other by design, but differently:

A properly sandboxed app still leaks data constantly through its own storage, logs, and backups if the developer doesn't apply the same secure-coding discipline covered in the Web Development roadmap's Secure Coding Practices Lab.

APK Structure and the Manifest

An Android APK is a ZIP archive containing compiled code (classes.dex), resources, and AndroidManifest.xml — the file declaring every permission, activity, service, and exported component. Two manifest attributes matter enormously for security:

• android:exported="true" on an activity/service/receiver — makes that component callable by any other app on the device, not just your own
• android:debuggable="true" left in a release build — allows attaching a debugger and inspecting/modifying the running app

Insecure Local Data Storage

Mobile OWASP's most common finding class. Apps routinely store sensitive data (tokens, PII, sometimes credentials) in locations that are recoverable on a rooted/jailbroken device or via a backup:

Intents and Deep Links: Inter-App Attack Surface

Android's intents let apps request actions from each other or the OS; an exported component with no permission check can be invoked by any malicious app installed on the same device. iOS deep links (custom URL schemes, Universal Links) similarly let other apps or even a malicious webpage trigger actions inside your app — if the app trusts the deep link's parameters without validation, this becomes an injection point functionally similar to an unvalidated web form.

The OWASP Mobile Top 10

The mobile-specific counterpart to the Web Top 10 covered earlier — key categories include: Improper Credential Usage, Inadequate Supply Chain Security, Insecure Authentication/Authorization, Insufficient Input/Output Validation, Insecure Communication, and Insufficient Cryptography. Many map directly to concepts already covered (input validation, TLS/certificate pinning, secure storage) applied to the mobile context specifically.

Certificate Pinning and Root/Jailbreak Detection

Certificate pinning hardcodes which certificate (or public key) an app trusts for its backend API, rather than trusting any certificate a device's trust store accepts — defending against a MITM using an otherwise-valid but attacker-controlled certificate (e.g. from a compromised or malicious CA, or a corporate MITM proxy). Root/jailbreak detection attempts to identify a device that's had its OS security model bypassed, since a rooted/jailbroken device can defeat local storage protections, tamper with the running app, or bypass certificate pinning entirely.

Common Pitfalls

• Leaving android:debuggable="true" or exported components without permission checks in a shipped release build
• Storing sensitive data in plaintext, assuming the OS sandbox alone is sufficient protection
• Trusting deep link/intent parameters without the same input validation applied to a web form
• Treating certificate pinning and root detection as unbreakable controls rather than one layer of defense in depth — determined attackers on their own device can often bypass both