Mobile app security: the complete reference

Mobile app security is the set of practices, controls, and automated checks that keep a published Android or iOS app resistant to the threats it faces in production. It covers the app binary itself, the runtime it executes in, the network traffic it generates, the data it stores, the third-party SDKs it loads, and the build pipeline that produces it.

Three things make mobile different from web security: the attacker has full read access to your shipped binary, the device you're running on cannot be trusted, and the platform store (Apple, Google) is a hard distribution gate. Every control in this cluster is shaped by those three facts.

The Open Worldwide Application Security Project (OWASP) publishes the canonical list of mobile risk categories. The 2024 revision is what most scanners — PTKD included — map findings against. The categories below appear across every guide in this cluster:

• M1 — Improper credential usage: hardcoded secrets, weak token storage, predictable session handling.
• M2 — Inadequate supply chain security:vulnerable third-party SDKs, unsigned dependencies, compromised build pipelines.
• M3 — Insecure authentication / authorisation:broken biometric flows, missing server-side checks, token replay.
• M4 — Insufficient input / output validation:WebView injection, SQL injection in local databases, unsafe deep-link handlers.
• M5 — Insecure communication: missing TLS, cleartext fallback, broken certificate pinning.
• M6 — Inadequate privacy controls:over-broad permissions, leaked PII in logs, missing consent.
• M7 — Insufficient binary protection:no obfuscation, no anti-tampering, exposed strings.
• M8 — Security misconfiguration:debug builds shipped, exported components, overly permissive manifests.
• M9 — Insecure data storage:plaintext SharedPreferences, unencrypted Keychain entries, world-readable files.
• M10 — Insufficient cryptography:custom crypto, weak algorithms, predictable keys.

Every page in this cluster assumes a hostile execution environment. Specifically, the attacker can: install your app on a rooted device, attach a debugger, intercept network traffic with a custom CA, decompile your binary, replay requests, and tamper with local storage. Any control that breaks under those assumptions doesn't belong in your app.

What the attacker generally cannot do — assuming your backend is sound — is forge a server-validated session, decrypt hardware-bound key material, or bypass Apple/Google's code signature. Most real production security work is pushing trust off the device toward your servers and the platform attestation APIs.

Apps built with Cursor, Rork, FlutterFlow, Adalo, Bubble, and Glide produce predictable security patterns: hardcoded API keys in client config, SQL composed via string concatenation, authentication shimmed onto pages that should have been server-protected, and untrusted user input flowing into native bridges. Traditional SAST tools — built for hand-written Swift and Kotlin — frequently miss these because the vulnerable code lives in generated JSON, YAML, or compiled JavaScript bundles.

Several guides in this cluster are tuned for those patterns. If you're shipping an AI-coded app, start with the Rork-specific pages and the "testing AI-generated apps for vulnerabilities" guide before working through the rest of the cluster.