Insecure local storage
Insecure local storage is the retention of sensitive data on a mobile device in a form that another application, a person with the handset, or a backup can read. It is the most frequently reported finding in mobile assessments and the easiest to demonstrate, because it needs no exploit at all.
The pattern is nearly always the same. A session token, a refresh token, an API key, a full response containing personal data or a copy of a document is written to the application’s own storage area for convenience, in a preferences file, an unencrypted local database or a cache directory. Within the application sandbox that feels private, and it stops being private the moment the device is unlocked and inspected, restored from a backup, or shared with an application that has been granted broad file access.
The platforms provide the correct place: a hardware backed keystore for key material, and platform encryption tied to device unlock for anything else that persists. The failures are not ignorance of those facilities but shortcuts around them, such as a key stored beside the data it protects, or a keystore protected value also cached elsewhere in the clear.
Two things get missed in reviews. Logs, written during development and left enabled, which a diagnostics export makes readable. And platform behaviour outside the application’s control, such as automatic cloud backup of the data directory and the screenshot the system takes when the application is backgrounded. What we do is exercise the application normally and then read everything it left behind, checking it against the storage requirements of the OWASP MASVS and against the encryption at rest claims in the client’s own documentation. That is the mobile testing where the device filesystem is examined after ordinary use.