{"id":100022,"date":"2026-10-29T22:08:26","date_gmt":"2026-10-29T22:08:26","guid":{"rendered":"https:\/\/www.nandee.ai\/blog\/mobile-app-security-checklist-for-2026\/"},"modified":"2026-11-06T18:39:19","modified_gmt":"2026-11-06T18:39:19","slug":"mobile-app-security-checklist-for-2026","status":"publish","type":"post","link":"https:\/\/www.nandee.ai\/blog\/mobile-app-security-checklist-for-2026\/","title":{"rendered":"Mobile App Security Checklist for 2026 (Android and iOS)"},"content":{"rendered":"

A security checklist is only useful if a real team can run it before a real release. This one is built to do exactly that. It is organized by area, ordered roughly by how often each issue leads to a real breach, and it maps to the OWASP Mobile Top 10 (2024)<\/a> so you can see why each item is here.<\/p>\n

Use it as a pre-release gate, a code review guide, or the starting point for your own standard. It applies to native Android, native iOS, and cross-platform apps built with React Native or Flutter.<\/p>\n

Quick answer:<\/strong> The highest-impact items are to keep secrets off the device, store tokens in Keystore or Keychain, enforce authorization on your server, encrypt and validate all network traffic, lock down your app configuration, and automate these checks in CI so they run on every build.<\/p>\n

1. Credentials and secrets (M1)<\/h2>\n

\u2610 No third-party secret keys in source code, resources, or build config<\/p>\n

\u2610 Public SDK keys restricted to your package name, signing certificate, or bundle ID<\/p>\n

\u2610 Backend issues short-lived, narrowly scoped tokens for any direct service access<\/p>\n

\u2610 User session tokens stored in Android Keystore or iOS Keychain, never plain storage<\/p>\n

\u2610 OAuth 2.0 with PKCE and the system browser for sign-in; no stored passwords<\/p>\n

\u2610 No credentials in URLs, logs, or crash reports<\/p>\n

\u2610 Every secret that ever shipped has been rotated<\/p>\n

\u2610 Secret scanning runs on every pull request and release build<\/p>\n

2. Authentication and authorization (M3)<\/h2>\n

\u2610 Every API enforces authorization on the server, on every request<\/p>\n

\u2610 The app never decides access rights on its own (no client-only role checks)<\/p>\n

\u2610 Object access is checked by owner, so one user cannot read another\u2019s data by changing an ID<\/p>\n

\u2610 Sessions use short-lived tokens with server-side revocation<\/p>\n

\u2610 Sensitive actions require re-authentication or step-up where appropriate<\/p>\n

\u2610 Biometric unlock gates access to a securely stored key, not just a UI screen<\/p>\n

3. Data storage (M9)<\/h2>\n

\u2610 Sensitive data is kept on the server unless it must be offline<\/p>\n

\u2610 On-device sensitive data is encrypted with a Keystore or Keychain-backed key<\/p>\n

\u2610 The strictest practical iOS data protection class and Keychain accessibility are used<\/p>\n

\u2610 No sensitive data in external storage, logs, caches, or the clipboard<\/p>\n

\u2610 Sensitive screens are hidden from screenshots and the app switcher where it matters<\/p>\n

\u2610 Backups exclude sensitive files (Android backup rules, iOS backup exclusion)<\/p>\n

4. Network communication (M5)<\/h2>\n

\u2610 All traffic uses TLS; cleartext is blocked<\/p>\n

\u2610 Certificate validation is never disabled or overridden<\/p>\n

\u2610 Certificate or public-key pinning is used for high-risk APIs, with a backup pin<\/p>\n

\u2610 App Transport Security is enabled on iOS with justified exceptions only<\/p>\n

\u2610 No sensitive data is sent in URL query parameters<\/p>\n

5. Platform configuration (M8)<\/h2>\n

\u2610 android:debuggable<\/code> is off in release builds<\/p>\n

\u2610 Backups are restricted appropriately<\/p>\n

\u2610 Every exported Android component is reviewed and protected or made private<\/p>\n

\u2610 iOS NSAllowsArbitraryLoads<\/code> and other development exceptions are removed<\/p>\n

\u2610 The app requests only the permissions its features need<\/p>\n

\u2610 The merged manifest and Info.plist are reviewed before each release<\/p>\n

6. Input and platform interaction (M4)<\/h2>\n

\u2610 Deep links and App Links validate every parameter before acting on it<\/p>\n

\u2610 Incoming intents and inter-process messages are treated as untrusted input<\/p>\n

\u2610 WebViews load only trusted origins and limit native bridges<\/p>\n

\u2610 Database queries and content providers use parameterized queries<\/p>\n

\u2610 Verified App Links or Universal Links are used for sensitive flows<\/p>\n

7. Privacy (M6)<\/h2>\n

\u2610 The app collects the minimum data its features require<\/p>\n

\u2610 Personal data is kept out of logs, crash reports, and analytics<\/p>\n

\u2610 Third-party SDKs initialize only after consent where required<\/p>\n

\u2610 The Google Play Data safety form is accurate and matches SDK behavior<\/p>\n

\u2610 The iOS privacy manifest is present and accurate<\/p>\n

\u2610 Users can access and delete their data as required by law<\/p>\n

8. Dependencies and supply chain (M2)<\/h2>\n

\u2610 Dependency versions are pinned and lockfiles are committed<\/p>\n

\u2610 A software bill of materials (SBOM) is generated for each release<\/p>\n

\u2610 Each SDK\u2019s data collection and added permissions have been reviewed<\/p>\n

\u2610 Software composition analysis runs across Gradle, CocoaPods, SwiftPM, npm, and pub<\/p>\n

\u2610 Signing keys and CI secrets are protected like production credentials<\/p>\n

9. Cryptography (M10)<\/h2>\n

\u2610 Modern algorithms only (AES-GCM for data), with platform-held keys<\/p>\n

\u2610 A fresh random nonce or IV is used for each encryption<\/p>\n

\u2610 No MD5 or SHA-1 for anything security-relevant<\/p>\n

\u2610 No home-made cryptography; platform crypto APIs are used<\/p>\n

10. Testing and release<\/h2>\n

\u2610 Static analysis (SAST) runs on every pull request<\/p>\n

\u2610 Dynamic testing runs on a real or emulated device per release<\/p>\n

\u2610 A manual or AI-assisted penetration test runs before major releases and at least yearly<\/p>\n

\u2610 Release builds have code shrinking and obfuscation enabled<\/p>\n

\u2610 Debug logging is stripped from release builds<\/p>\n

\u2610 High-severity findings block the release until fixed<\/p>\n

How to use this checklist<\/h2>\n

Three ways teams get value from it:<\/p>\n

    \n
  1. As a release gate.<\/strong> Require the relevant boxes to be ticked before shipping. Automate as many as you can in CI so the gate is not just a document.<\/li>\n
  2. As a review guide.<\/strong> Use the relevant section during code review for features that touch auth, storage, or networking.<\/li>\n
  3. As a standard.<\/strong> Adapt it into your own written security standard and map it to OWASP MASVS<\/a> for audits and enterprise reviews.<\/li>\n<\/ol>\n

    The items you cannot easily check by hand, such as hardcoded secrets across a large codebase or insecure storage calls, are the ones worth automating first.<\/p>\n

    FAQ<\/h2>\n

    How often should I run a mobile app security checklist?<\/strong> Run the automated parts on every build, the full checklist before each release, and a deeper manual or AI-assisted test before major releases and at least once a year.<\/p>\n

    Does this checklist cover both Android and iOS?<\/strong> Yes. Most items apply to both platforms, with a few platform-specific notes for manifests, Info.plist, Keystore, and Keychain.<\/p>\n

    How does this relate to the OWASP Mobile Top 10?<\/strong> Each section maps to one or more of the Top 10 risks, shown in the headings, so you can trace every item back to the risk it addresses.<\/p>\n

    Can I automate this checklist?<\/strong> Many items can be automated with static analysis, dependency scanning, and configuration checks in CI. Manual review is still needed for business logic and authorization.<\/p>\n

    Turn this checklist into automated checks<\/h2>\n

    Nandee is an AI-assisted mobile application security testing platform for Android and iOS apps. It automates the items on this list that a tool can catch, ranks what it finds by risk, and gives your developers fixes to review.<\/p>\n

    Sources<\/h2>\n