# Scope a mobile security test: the app, the device and the API are separate boundaries Canonical: https://www.web3sec.news/blog/scope-mobile-app-security-test Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Mobile assessment scope Published: 2026-11-08 Updated: 2026-11-08 Prepare Android and iOS builds, device coverage, representative accounts and acceptance criteria so a mobile assessment answers a real release question. ## The short answer Scope mobile testing around installable builds, supported devices, sensitive user journeys and the APIs that enforce permissions. Include local data, session lifecycle, platform entry points and release configuration. Agree on source access, instrumentation and limitations, then tie findings and retests to exact app and backend versions rather than treating a scanner result as complete coverage. ### Diagram: A trusted app still needs server authorization. Review device, link, session and API boundaries separately. ![External links and SDK inputs enter the mobile app's current session. The server independently checks identity, tenant and action before returning a protected record. Local Keychain or Keystore controls protect device-held material but do not replace server authorization.](https://www.web3sec.news/diagrams/mobile-app-boundaries.svg) [Full-size SVG](https://www.web3sec.news/diagrams/mobile-app-boundaries.svg) · [PNG download](https://www.web3sec.news/diagrams/mobile-app-boundaries.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Begin with the release decision and its artifacts The product owner should name the decision the assessment will support: a release, a new authentication flow, a changed payment journey or a sensitive SDK integration. Record the app identifiers, version and build numbers, distribution route, source commit where available and relevant backend environment. Identify the technical owner who can explain intended behavior and the release owner who will evaluate remaining risk. Record which release changes are motivating the assessment and their dependencies. Provide installable Android and/or iOS artifacts through an agreed private channel. Define the device and OS matrix, supported account roles, representative data and allowed techniques. Source-assisted access can improve understanding, while runtime access demonstrates what the supplied build actually does. If observation requires an instrumented or special test build, record how it differs from the intended release and which conclusions depend on that difference. ## Map client, platform and server responsibilities OWASP MASVS organizes mobile verification requirements across areas including storage, authentication, network, platform interaction and privacy; MASTG provides testing methods. Use relevant requirements to make coverage discussable, with exclusions explicit. Do not turn a reference to the standard into a claim that every requirement was tested, a fixed profile was satisfied or a certification was awarded. Trace sensitive journeys from local UI to the server decision. A hidden screen, local biometric prompt or difficult-to-modify client does not establish which records the backend permits an account to access. Include login, recovery, account switching, logout, refresh and sensitive actions. Use controlled accounts to compare permitted behavior with prohibited cross-user or cross-tenant behavior, and keep destructive or production actions outside the procedure unless separately authorized. ## Review where sensitive state persists Inventory credentials and sensitive records in files, databases, preferences, logs, caches, backups, clipboard, notifications and snapshots where relevant. Android documents Keystore protection and restrictions on key use; Apple documents Keychain protection classes and access conditions. Verify the implementation’s selected settings and actual behavior instead of accepting a secure-storage library name as proof that every token or copied value is protected. With synthetic data, observe what remains after logout, account changes, device locking, app updates and relevant backup or restore workflows. Distinguish non-exportable key material from an operation an already compromised app process may still request. Record the stock, instrumented or modified-device conditions required for an observation. This makes impact assessable without implying that every local extraction scenario works against an ordinary user’s locked phone. ## Set evidence and retest expectations before delivery Ask for findings that identify the affected build, device conditions, prerequisites, observed boundary and responsible control layer. Include sanitized evidence and a reproducible path where appropriate, alongside coverage and uncertainty. Review third-party SDK and release configuration changes that may alter data flows, but distinguish tested runtime observations from legal privacy conclusions or assumptions about all future SDK behavior. Agree on which fixes and review rounds are included. A retest should identify both the patched app artifact and any changed server behavior, repeat prohibited cases and preserve legitimate baseline flows. Assign engineering owners to changes and a decision owner to residual risk. Keep later app versions, new permissions and additional platforms outside the result unless they are actually examined through an updated scope. ## Controls to take away - A mobile assessment includes more than an API test or package scan. - Shared framework code does not remove platform-specific behavior. - Secure-storage settings and tested release artifacts need direct verification. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Name the release question, app artifacts and backend environment. - [ ] Agree devices, OS versions, roles, distribution and allowed techniques. - [ ] Map local data, platform entry points and server authorization separately. - [ ] Use synthetic data and record instrumentation-dependent conclusions. - [ ] Tie retesting to patched app and backend versions with positive and negative cases. ## Common questions ### Does reviewing the API cover the mobile app? No. API testing examines server-side behavior, while storage, platform components, deep links, WebViews and release settings need client-side examination. Identify both boundaries and the paths actually included in the proposal. ### Can a Flutter or React Native app be reviewed only once for both platforms? Shared code can support shared analysis, but native plugins, permissions, storage, links and release configuration still differ by platform. Agree which Android and iOS artifacts and device conditions will be examined. ### What should be supplied before runtime testing begins? Provide authorized installable builds, test accounts, synthetic data, important workflows and environment details. Agree on distribution and observation requirements; do not send private signing keys or unrestricted production credentials as routine inputs. ## Sources & further reading - [OWASP: Mobile Application Security Verification Standard](https://mas.owasp.org/MASVS/) - [OWASP MASTG: mobile application security testing methods](https://mas.owasp.org/MASTG/0x04b-Mobile-App-Security-Testing/) - [Android: Keystore protection and key-use restrictions](https://developer.android.com/privacy-and-security/keystore) - [Apple: Keychain data protection and access conditions](https://support.apple.com/en-ca/guide/security/secb0694df1a/web) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)