What Your Mobile App Leaves Behind

01 / Mobile application security

Start with a data map

Choose a realistic workflow, such as viewing an invoice or downloading a report. Record which information comes from the server, why the app stores it, and how long it is useful. Include embedded browser content and any sharing or export feature.

OWASP MASVS-STORAGE-1 addresses protection of sensitive data intentionally stored by an app, whether its location is private or public. MASVS-STORAGE-2 addresses unintended leakage through facilities such as logs and backups. This distinction helps structure a review: necessary storage and accidental copies deserve separate attention. [1] [2]

For each copy, write down an owner and a deletion condition. If a team cannot explain why a copy exists, investigate whether the workflow can operate without creating it.

02 / Mobile application security

Examine local storage in context

Private app storage, a downloaded file, and a shared folder have different exposure paths. MASVS-STORAGE-1 expects sensitive information to be protected independently of where it is stored. [1]

Our suggested review includes local databases, preferences, temporary files, document previews, and exports. Ask whether the design uses appropriate platform storage protections and whether access matches the sensitivity of the information. Test with synthetic records on supported devices so evidence can be retained without collecting real customer data.

Illustrative scenario: A field worker downloads a report to work offline. That may be an intentional feature. The assessment should establish who can open the copy, how its lifetime is limited, and what happens after the worker loses access to the project. A blanket instruction to remove all offline storage would miss the product requirement.

03 / Mobile application security

Make diagnostic output part of the assessment

Android’s security guidance describes how sensitive information in logs can disclose credentials or personal data and recommends avoiding sensitive logging. Review diagnostics in the build customers receive, rather than assuming development settings describe release behavior. [3]

Inspect sign-in, network failures, document handling, and crash-reporting paths. Ask support teams what they request from users during troubleshooting. A useful diagnostic record explains the failure without reproducing a password, session token, full document, or unnecessary personal information.

Give developers a redaction rule and a way to test it. Request identifiers and error categories may provide enough context for an investigation, but their suitability should be checked against your actual support workflow.

04 / Mobile application security

Test backup and restore, not just configuration

Android Auto Backup includes many app files by default and supports inclusion and exclusion rules. Its documentation distinguishes rules according to Android version and transfer type. Review the rules that apply to the versions your app supports and verify the outcome through a restore test. [4]

Extend the same question to each supported platform using its current documentation: what information moves to another device, and under which conditions? Include exports and cloud synchronization in the inventory instead of treating every copy as an operating-system backup.

A restore should not be assumed to preserve valid business authorization. Ask whether the restored app needs to obtain current permissions before showing sensitive content or resuming a privileged workflow.

05 / Mobile application security

Check the moments between users and devices

Our recommended test sequence uses two synthetic accounts and covers a fresh install, sign-in, offline use, backgrounding, sign-out, account switching, and restore. Observe what remains visible or accessible at each transition. Check previews and notifications as well as the main interface.

• Can account B see information retained from account A?
• Does removing a downloaded item remove the copies the app controls?
• What remains after a session expires while the device is offline?
• Can support investigate an error without receiving sensitive files?
• Is the behavior consistent with the product’s stated retention policy?

Record the app build, operating-system version, device state, and reproduction conditions. This makes a finding actionable and gives the next release a concrete regression check.