Home / Knowledge hub / Insecure data storage on mobile
Knowledge hub
Insecure data storage on mobile
A phone app saving tokens or personal data where other apps or people can read it.
What it means
Insecure data storage on mobile means a phone app saves sensitive information, such as a session token, a password or personal records, in a place it should not be. Plain files, local databases, preference files, logs, backups and the clipboard are common culprits.
The operating system tries to keep apps apart, but that protection is not absolute. A lost phone, a rooted or jailbroken device, a device backup, or a malicious app with the right access can expose what your app left lying around.
Why it matters
A stolen session token stored in plain text can let someone act as the customer until it expires. Stored personal data can turn a lost phone into a privacy incident. OWASP lists insecure data storage in its Mobile Top 10 for this reason.
It is also a cheap finding for a tester. Opening the app's data folder on a test device takes minutes and often reveals tokens, API keys or full customer records. Anything an app holds can be read by someone with the device, so assume that it will be.
How it shows up
Look at what the app writes to disk: preference files, SQLite databases, cache folders and log output. Check whether sensitive values are in app backups, screenshots taken when the app is sent to the background, and the clipboard. Hard-coded keys inside the app package are a related problem; see hardcoded secret.
Use the platform's secure stores, the iOS Keychain and the Android Keystore, for secrets and tokens. Keep tokens short-lived, so one that leaks soon expires, and make revocation work on the server. Store less in the first place, as covered under data minimisation.
Questions people ask
Insecure data storage on mobile, answered
Is data safe if the phone has a passcode?
A passcode and device encryption help against a lost phone. They do not protect against a malicious app on a rooted device, an unprotected backup, or data your app sent to a log.
Defence in depth still applies.
Where should an app store a session token?
In the platform's secure storage: the iOS Keychain or the Android Keystore. Not in plain preference files or a local database.
Keep the token short-lived and revocable on the server.
Does encrypting a local database fix it?
Only if the key is protected. A key stored next to the database, or inside the app, gives little protection.
Tie keys to the platform's secure storage. Rotate the key when a device is lost.
How do we test for it?
Use the app on a test device, then inspect its data folder, backups, logs and screenshots for tokens and personal data.
The OWASP testing guide lists steps for both iOS and Android.
Can the server limit the damage?
Yes. Short token lifetimes, revocation on logout or password change, and checks that a token only reaches its own account reduce what a stolen token can do.
These checks run on the server, not the phone.
Sources
Where this comes from
Related
Terms that sit next to this one
OWASP MASVS
A standard listing what a secure mobile app should do.
Mobile penetration testing
Testing a mobile app and the services it talks to for security flaws.
Session token
A random value the browser sends to show it belongs to a signed-in visit.
Hardcoded secret
A password, API key or token written straight into source code.
Web storage security
The risk of keeping tokens in localStorage, where any script on the page can read them.
What can a stolen token do?
If a token leaks from a phone, your server decides what it can reach. We test the API behind your app for cross-account access, with the request and response as proof. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.