Illustrative case: records after logout
Consider an illustrative field-service app that downloads customer job records for offline use. A technician logs out while disconnected and sees the sign-in screen. Reopening the app, however, exposes cached customer details. The backend correctly rejects the old session. There is no contradiction: the server session and local cache have different lifecycles, and the remaining question concerns how the app handles its local data.
First establish the intended offline policy. The workflow might deliberately retain encrypted data for a named user. If so, test what should happen after logout, account disablement, device sharing and expiry of offline authorization. Those conditions determine whether the retained data matches the design or demonstrates a defect.
Locating the observation in the mobile system
Identify the release artifact, device and operating-system version with each result. The matrix keeps observations attached to the layer that produced them. A successful check on one build or device cannot answer the same question for a combination that was never tested.
| Boundary | Test | Evidence boundary |
|---|---|---|
| Release package | Confirm build identity, signing and debug settings | The artifact hash and distribution channel identify the release under review. |
| Local storage | Inspect permitted caches, logs and backup behavior | The device or emulator, inspection method and its limitations qualify the observation. |
| Platform interaction | Exercise notifications, links and file sharing | The record identifies the exposed data and the receiving application. |
| Authentication | Logout, expiry, recovery and offline transitions | Both app state and the backend session result are observed. |
| Backend authorization | Attempt cross-account access with synthetic records | The server rejects the unauthorized object or function request. |
Run the state transitions
Use synthetic accounts and records to follow installation, upgrade, restart, backgrounding, lost connectivity and reauthentication. Check what remains visible in notifications and the application switcher during those transitions. For incoming links, include another customer's record identifier and verify the account's actual authority. The identifier alone must not grant access to that record.
OWASP MASVS organizes requirements for storage, cryptography, authentication, networking, platform interaction, code, resilience and privacy. Select the requirements relevant to this release. For each one, record the method and observed result against the identified build. A list of requirement IDs without those observations leaves unclear what was actually tested.
- Supported iOS and Android releases need separate observations.
- An emulator result should be compared with the relevant physical-device behavior.
- Any device modification used for inspection is part of the conditions of the result.
- Manipulated app input must still encounter effective authorization checks at the backend.
Limits and follow-up
One device does not represent every hardware security implementation, manufacturer image or OS version. Enrollment and organizational policy can also change the controls in effect. Record these conditions so the work can be reproduced and the remaining configurations can be identified. The worksheet does not provide a mobile certification or establish that all attack techniques were exercised on untested devices.
Sources and reference editions
- OWASP Mobile Application Security Verification StandardCurrent online standard inspected 2026-10-03
- MITRE ATT&CK August 2026 release19.2, 2026-08-06