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.
Take this to your next review
Working checklist
Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.
0 of 5 reviewed
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
The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.
A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.