OWASP Mobile Security Testing Checklist for iOS and Android Apps

Most standard OWASP Mobile Security checklists for mobile app testing treat iOS and Android as if they’re the same OS with different logos. They’re not. The attack surface on Android’s open component model looks nothing like iOS’s sandboxed Keychain architecture. Running the same generic checklist on both platforms doesn’t just miss things; it gives engineering teams false confidence that they’ve actually checked. We’ve run security audits across both platforms, and the pattern is consistent: teams that use a unified checklist tend to catch the obvious stuff (hardcoded API keys, cleartext HTTP) but miss the platform-specific vulnerabilities that are actually more likely to get exploited in production.

This checklist is structured differently. It starts with the checks that apply to every mobile app, then breaks into iOS-specific and Android-specific sections where the attack surfaces genuinely diverge.

Before you start: According to the OWASP Mobile Application Security (MAS) standard, every OWASP Mobile Security program should map its testing to the OWASP Mobile Top 10. This checklist does exactly that, organized around the checks that matter most in 2026.

What This Checklist Covers

• Universal checks that apply to both platforms
• iOS-specific checks (Keychain, ATS, entitlements, backgrounding snapshots)
• Android-specific checks (AndroidManifest, exported components, WebView, external storage)
• A quick-reference comparison table at the end

These apply regardless of platform. If your app fails any of these, platform-specific checks are secondary concerns.

Authentication and Session Management

• Session tokens are not stored in plaintext (SharedPreferences, NSUserDefaults, or local files)
• Tokens expire after a reasonable inactivity window and are invalidated server-side on logout
• JWT tokens are validated with signature verification, not just decoded client-side
• Biometric authentication is used for high-risk operations, not just app unlock
• BOLA (Broken Object Level Authorization) attacks are tested: can user A access user B’s data by changing an object ID in an API request?

Data Storage

• No sensitive data (tokens, PII, credentials) written to plaintext logs
• Clipboard does not retain sensitive data after the user leaves the app
• SQLite databases do not store credentials or tokens in plaintext
• App does not write sensitive data to cache directories that persist across sessions

Network Security

• All traffic is HTTPS with no HTTP fallback endpoints
• Certificate pinning is implemented for sensitive endpoints and tested for bypass resistance
• API responses do not return more data than the client displays (over-fetching)
• Authentication tokens cannot be replayed from a different device

Third-Party SDKs and Supply Chain

This is the most underestimated risk vector in 2026. According to the Quokka State of Mobile App Security 2026 report, inadequate supply chain security is one of the top recurring findings across mobile audits.

• All third-party SDKs are checked against the National Vulnerability Database (NVD) for known CVEs
• A Software Bill of Materials (SBOM) is maintained for the full dependency tree
• Analytics and advertising SDKs are specifically reviewed for data collection behavior
• No SDK requests permissions beyond what the app itself needs

Binary Protections

• Hardcoded API keys, credentials, and secrets are absent from the compiled binary
• Debug flags and verbose logging are disabled in production builds
• Code obfuscation is applied to sensitive business logic
• The app implements root/jailbreak detection (where relevant to the threat model)

For OWASP Mobile Security compliance, iOS has a tighter sandbox than Android, but that doesn’t mean it’s easier to test thoroughly. The platform has its own unique attack surfaces, and several of them are routinely skipped in generic checklists.

Important 2026 context: With iOS 26, Apple removed jailbreak support on current production devices, meaning filesystem inspection, Keychain validation, and runtime behavior analysis now require virtualized environments or older hardware. If your team is testing on current iPhones without a jailbreak, you are missing critical validation checks.

Keychain and Secure Storage

• Credentials and tokens are stored in the Keychain, not in NSUserDefaults or plist files
• Keychain items use the correct accessibility level (kSecAttrAccessibleWhenUnlockedThisDeviceOnly for most sensitive data)
• Keychain items are not accessible to other apps (check entitlements for unintended Keychain group sharing)
• Sensitive data is stored using the Secure Enclave where the threat model warrants it

App Transport Security (ATS)

• Info.plist does not contain NSAllowsArbitraryLoads: true (this disables ATS globally)
• Any ATS exceptions are documented and scoped to specific domains, not wildcards
• Background modes declared in Info.plist are limited to what the app actually needs
• URL schemes are reviewed to ensure they cannot trigger sensitive actions via a crafted external link

Universal Links and URL Schemes

• Universal links are validated server-side via the apple-app-site-association file
• Custom URL scheme handlers validate all input parameters before processing
• Deep link handlers cannot be triggered to bypass authentication flows or reach admin-only functions

Backgrounding and Screen Snapshots

This one catches teams off guard. When iOS moves an app to the background, it takes a snapshot of the current screen to display in the app switcher. If your app was showing a payment screen, a token, or PII at that moment, that data is written to disk.

• Sensitive screens are obscured before the app enters the background (use UIScreen.main.isCaptured or overlay a blur view in applicationWillResignActive)
• The app does not display sensitive data on screens that are visible during multitasking transitions

Binary and Entitlement Review

• Info.plist entitlements are scoped to minimum required capabilities
• Binary string inspection is performed on the compiled IPA for embedded endpoints, test URLs, and leftover debug routes
• The release build does not include debug symbols or verbose logging output

Within the OWASP Mobile Security framework, Android’s open architecture is its greatest strength and its biggest security liability. The component model that makes Android so flexible (Activities, Services, Broadcast Receivers, Content Providers) is also what makes it uniquely exploitable when misconfigured. Most Android-specific vulnerabilities trace back to one root cause: something was marked exported="true" that shouldn’t have been.

AndroidManifest.xml Review

Start every Android assessment here. The manifest is the most information-dense file in the APK.

• android:debuggable="true" is absent from the production build
• android:allowBackup="true" is explicitly set to false (the default is true on older API levels, which enables ADB backup of app data without root)
• android:usesCleartextTraffic="false" is set in the manifest or enforced via a Network Security Config
• All declared permissions follow the principle of least privilege
• No sensitive activities, services, or content providers are marked android:exported="true" without a corresponding android:permission attribute

Exported Components and Intent Handling

This is the most Android-specific attack surface. Any component with exported="true" or an unprotected intent filter can be invoked by any other app on the device. Privilege escalation, data theft, and CSRF-style attacks against mobile apps almost always start here.

• All exported Activities are tested with crafted Intents containing unexpected or malformed parameters
• Content Providers are tested for SQL injection via URI parameters and path traversal
• Broadcast Receivers do not process sensitive actions without verifying the sender’s identity
• Deep link and intent filter handlers validate all input before acting on it
• Exported components that should be internal are explicitly set to android:exported="false"

WebView Security

WebView is a browser embedded in your app. A misconfigured WebView is effectively a local XSS vulnerability with access to native device APIs.

Per Android’s official security documentation:

• JavaScript is disabled in WebViews that only display static content (setJavaScriptEnabled is not called by default)
• addJavascriptInterface objects are removed via removeJavascriptInterface before loading untrusted content
• WebViews load content only over HTTPS; android:usesCleartextTraffic is false
• Untrusted URLs loaded in WebView are validated against an allowlist of domains
• postMessage and postWebMessage calls specify an explicit target origin, never *

Data Storage

• Sensitive data is stored in Android Keystore-backed EncryptedSharedPreferences, not plain SharedPreferences
• No sensitive data is written to external storage (/sdcard/), which is readable by any app with READ_EXTERNAL_STORAGE
• logcat output during authentication flows does not contain tokens, passwords, or PII
• SQLite databases storing sensitive data are encrypted (consider SQLCipher)

Here’s a side-by-side view of where iOS and Android diverge on the same security concern. These are the areas where a single-platform checklist will leave you with blind spots.

Not every check on this list carries the same risk. Here’s how we’d triage findings across both platforms:

Fix immediately (block the release):

• Authorization failures (BOLA/IDOR: user A can access user B’s data) are a top OWASP Mobile Top 10 risk
• Exposed secrets with real use (live API keys, credentials in the binary)
• Unsafe backend rules (misconfigured Firebase, open S3 buckets)
• Sensitive data transmitted over HTTP
• android:debuggable="true" in a production APK

Fix in the next sprint:

• Weak client-side controls (jailbreak/root detection gaps) bypassing the OWASP MASVS L2 requirements
• Overbroad logging that captures PII in crash reports
• ATS exceptions that are broader than necessary
• Exported Android components without permission protection
• WebView with JavaScript enabled unnecessarily

Track and monitor:

• Informational findings with no direct exploit path, non-critical to the OWASP MSTG
• Defense-in-depth gaps blocked by stronger upstream controls
• SDK versions that are outdated but have no active CVEs yet

The goal isn’t to achieve a perfect score before shipping. It’s to ensure that the “fix immediately” category is empty and that the rest has a documented remediation timeline.

Running this checklist manually before every release will work once. It won’t work at scale. The teams that maintain strong security posture over time are the ones that automate the repeatable checks and reserve manual testing for the nuanced ones.

A practical CI/CD integration looks like this:

• On every commit to auth, networking, or storage code: Run static analysis (SAST) to flag insecure API usage, hardcoded secrets, and risky configuration edits before the review window closes.
• On every build: Scan dependencies against known CVEs. New SDKs and version bumps should trigger an automatic check.
• On every release candidate: Run MobSF (Mobile Security Framework) for automated binary inspection. It surfaces exported component issues, hardcoded credentials, dangerous permission usage, and certificate problems in minutes.
• Annually (or after major architecture changes): Conduct a full manual penetration test. Automated tools catch the known patterns; manual testing catches the logic flaws and business-layer vulnerabilities that scanners miss.

The real risk of skipping this: According to the Quokka 2026 State of Mobile App Security report, the four most persistent findings across mobile apps are unencrypted HTTP traffic, SQL injection, weak cryptographic configuration, and hardcoded secrets. All four are preventable with automated scanning in the build pipeline. They keep appearing because teams treat security as a pre-release gate rather than a continuous process.

Stop Guessing. Get a Real OWASP Mobile Gap Report.

Get a Custom Quote

Frequently Asked Questions