Mobile App Security Review Checklist
Work through manifest, permissions, networking, storage, authentication, cryptography, logging, components, export, and deep-link checks — mark items complete, filter to what's left, and jump straight to the relevant reference entry.
Checklist
0 of 26 complete (0%)
Manifest0 / 3
Confirm android:debuggable is false (or absent) in the release build
OpenWhy this matters
A debuggable release build allows ADB attachment and inspection on any device — never appropriate for production.
Set android:allowBackup deliberately, not by default
OpenWhy this matters
The default allows full app data extraction via adb backup on unencrypted devices — decide explicitly rather than inheriting the platform default.
Confirm targetSdkVersion is current
OpenWhy this matters
Older target SDKs receive more permissive defaults for permissions and background behavior on newer OS versions.
Permissions0 / 3
Audit every declared permission against actual app functionality
OpenWhy this matters
An unused declared permission is pure attack surface with no corresponding benefit.
Document the justification for every dangerous-permission-group request
OpenWhy this matters
Location, contacts, SMS, and similar groups warrant a written reason a reviewer (or app store) can evaluate.
Verify bundled third-party SDKs aren't silently requesting extra permissions
OpenWhy this matters
A dependency's own manifest merge can add permissions the app team never explicitly requested.
Networking0 / 3
Confirm no cleartext HTTP endpoints remain in a release build
OpenWhy this matters
Cleartext traffic is trivially interceptable on any network the device joins.
Evaluate certificate pinning for high-value endpoints
OpenWhy this matters
Pinning defends authentication and payment endpoints against a broader class of interception than TLS alone.
Review ATS exceptions (iOS) and Network Security Config (Android) for scope creep
OpenWhy this matters
A broad exception added for one debug endpoint can end up covering far more than intended.
Storage0 / 2
Confirm tokens and PII use platform-encrypted storage, not plain SharedPreferences/SQLite
OpenWhy this matters
Plaintext local storage is trivially readable given root, jailbreak, or backup extraction access.
Check for sensitive files written to world-readable external storage
OpenWhy this matters
External storage is readable by any app holding the relevant storage permission, not just the app that wrote the file.
Authentication0 / 3
Confirm no custom TrustManager or certificate validator disables validation
OpenWhy this matters
An empty or overridden trust check silently defeats TLS's authentication guarantee.
Verify OAuth authorization-code flows implement PKCE
OpenWhy this matters
Mobile apps can't reliably keep a client secret confidential — PKCE is the mitigation designed for that constraint.
Confirm session tokens are stored in Keychain/Keystore, not SharedPreferences
OpenWhy this matters
Token storage location determines whether a device-level compromise also compromises the user's session.
Cryptography0 / 3
Confirm no DES, 3DES, MD5, or SHA-1 usage for security-relevant operations
OpenWhy this matters
These algorithms are cryptographically broken for security purposes even though they remain available in standard libraries.
Confirm no hardcoded encryption keys or IVs in source or resources
OpenWhy this matters
A hardcoded key is extractable from the binary by anyone who obtains it, defeating the encryption entirely.
Confirm block ciphers do not use ECB mode
OpenWhy this matters
ECB mode leaks structural patterns in the plaintext even when the underlying cipher is strong.
Logging0 / 2
Confirm logs never contain tokens, credentials, or PII
OpenWhy this matters
Debug logging that includes a token or password is one of the most common accidental data leaks in mobile apps.
Review what crash reporting / analytics SDKs actually capture
OpenWhy this matters
Third-party crash and analytics tooling can capture more request/response detail than the team realizes by default.
Components0 / 2
List every exported Activity, Service, and BroadcastReceiver and confirm each needs to be exported
OpenWhy this matters
An exported component with no permission requirement is reachable by any other app on the device.
Review broadcast receivers handling system events (boot, SMS, package-replaced)
OpenWhy this matters
These receivers are common, easily overlooked targets since they trigger without direct user interaction.
Export0 / 3
Confirm the release build is signed with the production key, not a debug keystore
OpenWhy this matters
The Android debug keystore is shared across every developer's environment and is not a secret.
Confirm APK Signature Scheme v2+ is used, not v1-only signing
OpenWhy this matters
V1-only signing is vulnerable to APK tampering exploits (e.g. the Janus class of attack) on older Android versions.
Confirm the iOS provisioning profile and entitlements match the intended distribution channel
OpenWhy this matters
An Enterprise-signed IPA bypasses App Store review entirely — verify that's actually the intended distribution path.
Deep Links0 / 2
Validate and sanitize every parameter a deep link or App Link can pass in
OpenWhy this matters
A deep link handler is an input entry point exactly like a network API — unvalidated parameters carry the same injection risk.
Review custom URL schemes for intent hijacking risk
OpenWhy this matters
A custom scheme claimed by more than one installed app creates ambiguity an attacker can exploit.