A mobile application assessment spans the shipped package, the operating system, device state, network communication and backend services. Scoping only an APK or IPA creates gaps where sensitive transactions actually cross those boundaries.

The checklist should define platform-specific work and shared backend work without paying twice for identical coverage or assuming one platform proves the other.

Involve mobile engineers, backend owners, identity specialists and operations during scoping. They can identify build accommodations, device-integrity dependencies, hidden APIs and production effects before those facts become delays or unjustified exclusions during execution.

Identify applications, platforms and ownership

List Android and iOS applications, package or bundle identifiers, app-store channels, enterprise variants and owners. Include companion apps or embedded modules only when authorised.

State native, hybrid or cross-platform framework and relevant versions. Shared code does not remove platform-specific manifests, entitlements and storage.

  • Package and bundle identifiers.
  • Distribution and signing channel.
  • Native and shared frameworks.
  • Third-party SDK ownership.

Fix the builds and backend environment

Provide production-equivalent test builds with version and provenance. Record debug flags, test hooks, symbols and differences from the public release.

Name backend hosts and environment. Define what happens when a build changes during testing and which build is used for retest.

Record the signing identity and distribution path for every supplied build. Testers and reviewers should be able to distinguish an authorised assessment build from a locally altered package and relate every finding to the build that produced the evidence.

  • Release and test build hashes.
  • Debug or instrumentation accommodations.
  • Backend environment mapping.
  • Change cut-off and replacement rule.

Choose the device and OS matrix

Use customer distribution and security-control differences to select representative OS versions and devices. State managed, rooted, jailbroken or emulator conditions.

Physical devices may be required for biometrics, hardware-backed keys, NFC or attestation. Ask the provider to justify each test condition.

Record which conclusions can be shared across devices and which depend on OS version, vendor implementation or secure hardware. Risk-based sampling is defensible when that logic is explicit and the omitted conditions remain visible.

  • Minimum and current OS versions.
  • Physical and virtual devices.
  • Root and jailbreak conditions.
  • Special hardware or management profiles.

Define static binary analysis

Include permissions, exported components, intents, deep links, URL schemes, entitlements, configuration, embedded endpoints, secrets, cryptography and dependencies.

State whether native libraries, obfuscated code, source maps or framework bundles require specialist review. Static indicators should be validated against reachable behaviour.

  • Manifest and entitlement review.
  • Decompilation and resource inspection.
  • Native library and framework analysis.
  • Dependency and embedded-secret validation.

Define runtime analysis

Scope instrumentation, debugger, proxy and filesystem observation while key journeys execute. Identify controls that may require approved bypass in a test build.

The goal is to prove data or authority impact, not report every client check that can be hooked on an attacker-controlled device.

  • Runtime method and device condition.
  • Application files and process behaviour.
  • Cryptographic and network calls.
  • Client-control bypass tied to effect.

Inventory local data and lifecycle

List tokens, personal data, documents, caches, databases and diagnostic artefacts. Include login, logout, account switching, backup, upgrade and uninstall.

Scope keychain or keystore configuration, shared storage, screenshots, clipboard, notifications, logs and crash output according to the threat model.

  • At-rest data classes.
  • Protected storage and access class.
  • Backup and shared-container behaviour.
  • Deletion and multi-user isolation.

Include platform entry points

Inventory deep links, universal or app links, intents, activities, extensions, document handlers and push actions. State expected authentication and parameter rules.

Include web views, JavaScript bridges and navigation boundaries. External apps and hostile content can cross into native authority.

  • Custom and verified links.
  • Exported or externally callable components.
  • Notification actions.
  • Web content and native bridges.

Scope transport and destinations

List first- and third-party hosts, background sync, analytics and update channels. Describe certificate pinning and trust configuration.

Clarify that pinning bypass may enable testing but is not automatically a vulnerability. Findings focus on incorrect trust, sensitive exposure or unsafe fallback.

  • Destination inventory.
  • TLS and hostname validation.
  • Pinning and test accommodation.
  • Background and offline network paths.

Map authentication and device trust

Include registration, login, MFA, biometrics, SSO, recovery, token refresh, logout and revocation. State how device binding or attestation affects server decisions.

Test lifecycle changes and failure modes. A biometric screen does not prove that the backend operation requires fresh authorization.

  • Account and session lifecycle.
  • Biometric and step-up actions.
  • Device registration and removal.
  • Attestation binding, freshness and fallback.

Scope backend APIs directly

Provide API contracts, roles, tenants and test accounts. Include direct authorization and workflow testing beyond intercepted mobile traffic.

Map each critical mobile action to the API and final server effect. Assign ownership if a separate API workstream exists.

  • Operation and token inventory.
  • Role-object-tenant matrix.
  • GraphQL or real-time channels.
  • Asynchronous jobs and callbacks.

List critical mobile journeys

Identify payment, transfer, document, chat, approval, recovery, offline and notification-driven workflows. Include alternate sequence and replay where risk warrants.

State test values, third-party effects and cleanup. The mobile scope should follow the journey across app, OS and backend.

  • High-impact state transitions.
  • Offline queues and retry.
  • Cross-device or cross-channel behaviour.
  • Authoritative final result.

Set safety, evidence and retest

Use designated accounts, devices, data and financial limits. Define production rules, crash handling, monitoring and emergency contacts.

Require build, OS, device and identity context in findings, plus coverage across client and backend. Define platform-specific retest and closure evidence.

When one platform is fixed before the other, the retest plan should state whether the shared root cause and each platform-specific implementation will be verified separately. A single successful build should not silently close both.

  1. Validate builds and device access.
  2. Reconcile platform and API matrices.
  3. Approve safe workflows and test values.
  4. Accept coverage and retest criteria.

Use the official OWASP Mobile Application Security Testing Guide, OWASP MASVS and OWASP API Security Top 10 to structure client, platform and backend scope.

Scope the mobile transaction end to end

A package is an important artefact, but customers experience a system of device, OS, identity and backend decisions. The scope must connect them.

WIMD builds platform matrices and workflow evidence plans that let vendors price the same product risk and let buyers verify closure consistently and independently.