Mobile App Security
Assessment Checklist

Every permission is a surface area. Request only what the app genuinely needs; unused permissions are risk with no benefit. Review both the declared list and whether the usage description (iOS) or purpose string is honest about why the permission is needed.

• ☐Audit all declared permissions against actual app functionality. Remove any that are unused.OWASP M1 · Improper Platform Usage
• ☐Flag high-risk permissions and document the legitimate use case for each.Android: READ_SMS, READ_CALL_LOG, RECORD_AUDIO, SYSTEM_ALERT_WINDOW, REQUEST_INSTALL_PACKAGES, BIND_ACCESSIBILITY_SERVICE
• ☐Verify that "always-on" or continuous-access permissions are genuinely required — not just convenient.iOS: NSLocationAlwaysUsageDescription, NSUserTrackingUsageDescription, NSHealthShareUsageDescription
• ☐Check that NSUsageDescription strings accurately describe the actual use, not vague boilerplate.iOS
• ☐Confirm targetSdkVersion is current — older targets get more permissive defaults for some permissions.Android
• ☐Check that third-party SDKs bundled in the app are not silently adding permissions you didn't request.Both
• ☐If NSUserTrackingUsageDescription is present, confirm ATT consent is correctly requested before accessing IDFA.iOS

Any exported component (activity, service, receiver, provider) is reachable by any other app on the device. Exported components that handle sensitive actions or data without explicit permission checks are a common source of access control vulnerabilities.

• ☐List all activities, services, broadcast receivers, and content providers with android:exported="true".OWASP M1
• ☐Flag any component with an intent-filter but no android:exported attribute — implicit exports on older SDKs.Pre-API 31 behaviour
• ☐Verify that exported components requiring authentication or authorisation declare android:permission, and that the permission is not a custom one with Protection Level "normal".High impact if exposed without protection
• ☐Review content provider authorities and check that read/write permissions are enforced. Test path permissions if configured.Common vector for data exposure
• ☐Check exported broadcast receivers — especially those handling ACTION_BOOT_COMPLETED, ACTION_PACKAGE_REPLACED, or SMS-related broadcasts.Often overlooked
• ☐Review custom URL schemes and Android App Links for intent hijacking and data exposure risks.Deep links and app links

Secrets committed to source code or embedded in compiled binaries are a permanent record. Even after rotation, the old value remains in git history and in every copy of the original APK or IPA. Check code, configuration, and binary strings.

• ☐Scan source code for hardcoded API keys, tokens, and passwords using regex-based secret detection.OWASP M1 · CWE-798
• ☐Check whether .env files, .env.production, or .env.staging are committed to version control — including git history.Often contains real production credentials
• ☐Audit repository history (git log -S <pattern>) for credentials that were added and later deleted.CRITICAL if public repo
• ☐Check strings.xml, assets/, and res/raw/ for embedded credentials or configuration values that should vary by environment.Android
• ☐Scan compiled binary strings (DEX bytecode for APK, Mach-O binary for IPA) for secrets not visible in source: cloud provider patterns, JWT strings, PEM headers.Both — extract binary strings
• ☐Check Terraform .tfstate and .tfvars files — state files contain all infrastructure secrets in plaintext.Infra-as-code
• ☐Verify that CI/CD secrets (deploy keys, signing passwords, service account tokens) are stored as pipeline secrets, not in code or config files.Build pipeline
• ☐Confirm there is a documented process for rotating each class of credential if one is found in a scan.Key rotation plan

Insecure network configuration is frequently exploitable on any untrusted network. The platform-level controls (Android NSC, iOS ATS) provide a useful starting point, but certificate pinning and TLS configuration require explicit review beyond the defaults.

• ☐Review the Network Security Configuration file. Flag cleartext HTTP globally or per-domain, debug overrides, and trust of user-installed CAs.OWASP M3 · Android
• ☐Review NSAppTransportSecurity in Info.plist. Flag NSAllowsArbitraryLoads=true and per-domain exceptions with NSExceptionAllowsInsecureHTTPLoads.OWASP M3 · iOS
• ☐Check the AndroidManifest for android:usesCleartextTraffic="true" — this overrides NSC on API 23 and earlier.Android: usesCleartextTraffic
• ☐Search compiled binary strings for http:// URLs — cleartext endpoints embedded in code bypass NSC/ATS completely.Extract from binary strings
• ☐Determine whether certificate pinning is implemented for authentication or payment endpoints. Verify the pin is on the leaf or intermediate certificate, with a backup pin and a rotation plan.High-value endpoints
• ☐Confirm the server enforces TLS 1.2 or later and a secure cipher suite. The mobile client cannot enforce the server's configuration.Check server-side TLS independently
• ☐Check whether NSAllowsArbitraryLoadsForMedia or NSAllowsArbitraryLoadsInWebContent are used beyond their intended purpose.iOS · NSC debug override equivalent

Sensitive data stored insecurely on the device is accessible to other apps, backups, and physical device access. The platform provides secure storage APIs (iOS Keychain, Android Keystore) — the question is whether the app is using them for the right data.

• ☐Confirm sensitive data (tokens, credentials, PII) is stored using the Android Keystore rather than SharedPreferences or plain SQLite.OWASP M2 · Android
• ☐Confirm credentials and tokens are stored in the iOS Keychain with an appropriate accessibility attribute (kSecAttrAccessibleWhenUnlockedThisDeviceOnly preferred).OWASP M2 · iOS
• ☐Verify SharedPreferences files containing sensitive data use MODE_PRIVATE, not MODE_WORLD_READABLE or MODE_WORLD_WRITEABLE.Android · Common misconfiguration
• ☐Check android:allowBackup. If true, full app data can be extracted via adb backup on unencrypted devices. Consider android:fullBackupContent to exclude sensitive files.Android backup attack vector
• ☐Flag UIFileSharingEnabled=true — this makes the app's Documents directory accessible to desktop sync tools.iOS · Data accessible via Finder/iTunes
• ☐Check that crash reporters and debug logs do not include credentials, tokens, or PII. Log redaction is often overlooked.Logs and crash reports
• ☐Review Content Providers (Android) and App Groups / shared Keychain access groups (iOS) for unnecessarily broad data sharing with other apps.Cross-app data sharing

Signing controls who can update the app and, on Android, protects against certain binary tampering attacks. An unsigned, debug-signed, or V1-only signed release build is a significant finding in any assessment.

• ☐Verify the APK is signed with at least APK Signature Scheme v2. V1-only signing is vulnerable to the Janus attack on Android 5.0–8.0.OWASP M7 · CVE-2017-13156
• ☐Check that the release APK is not signed with the Android debug key. The debug keystore is shared across development environments and not a secret.Immediate finding in any assessment
• ☐Confirm the signing certificate is not self-signed for production distribution. Check certificate expiry and validity period.Android
• ☐Verify the IPA does not contain the com.apple.security.get-task-allow entitlement. This is added automatically to debug builds and must not appear in release builds.iOS · OWASP M8 · CWE-489
• ☐Check the provisioning profile type: App Store, Ad Hoc, Enterprise (ProvisionsAllDevices=true), or Development. Enterprise-signed IPAs bypass App Store review entirely.iOS · Different risk profile
• ☐Confirm the provisioning profile has not expired and the signing team is correct for the distribution channel.iOS
• ☐Document the key management practice: where are signing keys stored, who has access, and what is the rotation or revocation procedure?Both

Third-party libraries and SDKs introduce risk you didn't write and can't fully audit. Known CVEs in dependencies are the easiest class of finding to confirm — a version number match against a public database is definitive.

• ☐Cross-reference all direct dependencies against a public vulnerability database (OSV, NVD, GitHub Advisory). Prioritise CRITICAL and HIGH severity CVEs with available fixes.OWASP M8 · Start here
• ☐Check transitive (indirect) dependencies — these carry the same risk but are frequently overlooked.Often more than direct deps
• ☐Verify that dependency versions are pinned in lockfiles (package-lock.json, poetry.lock, Podfile.lock, etc.) to prevent unexpected version drift between builds.Version pinning
• ☐Review third-party analytics, advertising, and attribution SDKs. Determine what permissions they require, what data they transmit, and whether users are informed via the privacy policy.Android — broad data access
• ☐Check that dependencies are sourced from official registries (npm, PyPI, Maven Central, CocoaPods, SPM) and that the package name matches the expected publisher.Supply chain hygiene
• ☐Establish a policy for how quickly Critical and High CVEs in dependencies must be addressed. Dependency updates are often the most actionable category of finding.Low effort, high confidence

A scan that produces a list of issues is not an assessment. Triage turns raw findings into a risk-ranked, actionable set with clear status. Good triage makes the difference between a report that drives change and one that gets filed away.

• ☐Assign severity to each finding (Critical / High / Medium / Low) based on exploitability and impact, not just the scanner's default output.
• ☐Map findings to OWASP Mobile Top 10 or OWASP Top 10 (for source-code findings) for client reporting and prioritisation framing.OWASP M1–M10 on mobile; OWASP Top 10 on repo/SAST
• ☐Confirm each finding before including it in the final report. Document the confirmation method: reproduced via binary inspection, code review, or functional test.Scanners have false positive rates
• ☐Document false positives explicitly — include why the finding is a false positive so future assessors do not re-flag the same pattern.Required for risk register
• ☐For accepted risks (valid finding, business decision not to fix), document the rationale, the owner, and a scheduled review date.Requires written justification
• ☐Deduplicate findings of the same type and root cause — report once with the full list of affected locations, not as separate findings per file.Deduplication

The report is what creates change. A technically accurate report that developers and stakeholders can act on is more valuable than an exhaustive one they can't. Structure findings for two audiences: executives who need risk posture, and engineers who need specifics.

• ☐Write an executive summary that states overall risk posture, the most significant findings, and recommended priorities — without requiring technical knowledge to interpret.
• ☐Include a severity breakdown table: count of Critical, High, Medium, and Low findings.Severity distribution is a useful at-a-glance metric
• ☐State which OWASP Mobile categories are covered, which were tested, and which have open findings.Use the OWASP Mobile Top 10 as a framework
• ☐Each finding should include: title, severity, OWASP/CWE reference, precise location (file, line, or component), plain-English description, impact statement, and specific remediation steps.Engineers need this to fix the issue
• ☐Redact actual secret values in evidence snippets — show the pattern match and file path, not the raw credential. Reports are distributed to multiple recipients.Avoid exposing live credentials in reports
• ☐Include the scope: which builds (version, build number) were assessed, which source types (binary, repository, runtime), and when.Useful for re-assessment comparison

Security is a state, not an event. A single scan at release tells you about that build at that moment. Rescanning closes the loop: it verifies fixes, catches regressions, and builds the remediation record that demonstrates improvement over time.

• ☐After a fix is deployed, rescan the updated build or commit and confirm the finding no longer appears before changing its status to Fixed.Never close on developer self-reporting alone
• ☐When a finding reappears in a subsequent scan, reopen it — do not create a duplicate. The lifecycle history is the evidence of the regression.Regression detection
• ☐Establish a rescan cadence: at minimum, before every major release and after any significant dependency update. For active development, consider scheduled weekly or monthly scans.Recommended for most teams
• ☐Compare findings between scan runs to produce a delta: new findings, resolved findings, and findings that remain open. This is the clearest way to measure improvement.Delta view is more useful than a full new report
• ☐Review accepted-risk findings on a schedule (quarterly or annually). The business context or threat landscape may have changed since the risk was accepted.Accepted risks have a shelf life
• ☐Maintain a findings history that shows open count, fixed count, and severity breakdown over time. This is valuable for compliance reviews and client reporting.Demonstrates security posture improvement