Most mobile data leaks are not break-ins. They are side effects: data copied into backups, written to logs, left in caches, or captured in an automatic screenshot. MASVS-STORAGE-2 asks that the app prevent these leaks, and each one has a fix a developer controls.
Two different storage questions
The OWASP MASVS splits storage into two controls. STORAGE-1 is about data you store on purpose: it must be stored securely. STORAGE-2 covers the unintentional cases. Its description says these are cases where sensitive data ends up in publicly accessible locations "typically as a side-effect of using certain APIs, system capabilities such as backups or logs", and that the control covers leaks where the developer has a way to prevent it.
That second sentence is useful. You are not asked to stop everything the platform does, only what you can reasonably stop.
The usual leak points
Backups. The OWASP Mobile Application Security Cheat Sheet lists disabling backups on Android for sensitive apps. If an app's private files go into a cloud or computer backup, they leave the device sandbox. Decide which files belong in a backup and exclude the rest.
Logs. Debug logging that prints tokens, personal data or full request bodies is a classic leak. Logs can be read by tooling on a connected device and often get attached to bug reports. Strip verbose logging from release builds and never log secrets.
Background snapshots. The cheat sheet says to prevent leaks through caches, logs and background app snapshots. When an app goes to the background, the system may capture an image of the screen for the app switcher. If that screen shows a balance or a message, the image holds it. MASVS-PLATFORM-3 covers the same risk: data leaking through "auto-generated screenshots". Hide or blur sensitive screens when the app is backgrounded.
Caches. HTTP caches, image caches and web view caches can hold responses with personal data. Mark sensitive responses as not cacheable and clear caches at logout.
Shared locations. Anything written to a shared folder such as downloads is readable by other apps or the user. Keep sensitive files in app private storage.
Clipboard and keyboard. Fields that hold passwords or codes should not feed autocomplete or suggestion systems, and values copied to the clipboard may be readable elsewhere. Use secure field types.
A short audit you can run this week
- Build a release candidate and use the app normally with a proxy and a log viewer attached.
- Search the logs for tokens, email addresses, names and card or account numbers.
- Open the app switcher on each sensitive screen and look at the preview.
- Inspect what is in the app's private storage and what a backup would include.
- Log out, then look again. Did caches and files clear?
Write down each leak found, the data it exposed and the fix. Then add a check to your release routine so it does not come back.
Design so you leak less
The cheapest leak to prevent is data you never kept. The cheat sheet advises minimizing personal data, reducing how often it is collected and expiring it automatically. Less data on the device means less to leak through every channel above.
Where Safeguard fits
Some leaks come from libraries that log or collect more than you expect. Safeguard's SBOM and dependency scanning can show which components are in your build and which have known vulnerabilities. Try a free scan. Runtime behavior still needs the manual checks above.
Quick check
Is private app storage safe for tokens?
It is better than public storage, but the cheat sheet advises using the platform keystore for secrets. Keep tokens short lived and revocable.
Do iOS and Android leak the same way?
The categories are similar, but the mechanisms differ. Test each platform separately.
Sources
Last reviewed: 19 October 2026.
