Separate the requirement from the procedure
MASVS describes security controls. MASTG helps investigate whether an application satisfies relevant expectations. A control such as protecting sensitive stored data may require several procedures across files, databases, backups and logs.
Do not assume that running a tool named in a guide means the whole control has been assessed. Tools collect evidence; the application's behavior determines the result.
Build a small test case record
Objective: identify sensitive data written during a controlled login
Build: package, version and SHA-256
Environment: device/OS, test account and backend
Preconditions: clean install; synthetic account data
Actions: login, use feature, logout
Evidence: redacted file/log observations
Result: pass, fail, not applicable or not tested
Limitations: unavailable flows or unsupported device state
This record is intentionally specific enough for a second reviewer to repeat. Avoid storing live tokens or personal data in the report itself.
Select tests by feature
A camera-only offline utility and an authenticated payment client have different surfaces. Inventory local persistence, WebViews, exported components, external communication, authentication and third-party SDKs before selecting procedures.
For a feature that is absent, document why a test is not applicable. For a feature that could not be exercised, mark it not tested. Those conclusions should not be conflated.
Track the reference you used
MASTG content evolves. Record the test title or identifier and the source revision or review date alongside your evidence. Older blog posts may reference reorganized test IDs; follow the current official resource rather than guessing that a renamed page means a control disappeared.
Turn results into engineering work
A useful issue includes the affected artifact, the observed behavior, the violated boundary and a retest condition. “MASTG failed” gives a developer little to act on. “The release build writes the synthetic session token to an exported diagnostic log” is concrete.
APKLint's OWASP review page can structure preliminary checks and link observations. It is not a substitute for the device, account and backend access required to carry out the selected tests.
Turn a storage question into a repeatable observation
Take a test objective such as determining whether a synthetic session marker appears in unintended local files. Identify the application build, test account, marker and actions that create or clear the session. Use a fresh controlled installation, sign in, exercise the relevant feature and sign out. Inspect the authorized storage locations and logs according to the selected procedure.
The MASTG provides test techniques and platform context. Select the procedure that matches the feature and access available. If your environment cannot inspect a required storage surface, record that limitation instead of inferring a pass from the locations you could inspect.
Record the boundary that the marker crossed
A marker in a private encrypted record and the same marker in an exported diagnostic log have different implications. Record the location, relevant access conditions and the lifecycle point at which it appeared. Keep the marker synthetic so the evidence can be shared with the developer without including a user's real token.
Repeat after process restart and after sign-out. A cleanup path can remove the visible screen state while leaving the underlying record unchanged. Test the backup or export path separately when it is relevant; a local file inspection does not establish what another data-transfer mechanism includes.
Write the resulting issue as an observed behavior with a closure condition. For example, require the release diagnostic export to omit the synthetic session marker while preserving the non-sensitive information needed for support. This tells the developer what should change and lets a second tester reproduce the same check on a repaired artifact.
When retesting, retain the old and new artifact identities and use the same marker workflow. Add a legitimate-support-data check so the repair does not simply remove the entire diagnostic feature without review. Record the actual result and any remaining inaccessible surface.
Map this evidence to the relevant control in the chosen standard version. The mapping explains why the observation matters; it does not expand the test to every storage mechanism or every user journey in the application. Keep the report's claim as specific as the work performed.
Sources and further reading
- OWASP: Mobile Application Security Testing Guide
- OWASP: Mobile Application Security Verification Standard
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
