Insecure data storage is one of the risks in the OWASP Mobile Top 10. It happens when a mobile app stores sensitive information, such as usernames, passwords or card numbers, in a place where other apps or anyone with access to the device can read it.

The most common places where apps store data insecurely are:

• SQL databases
• Log files
• XML data stores / shared preferences
• Keyboard cache
• Copy/paste buffer (clipboard)
• HTML5 data storage
• Browser cookies

SQL databases

SQLite is the most common local storage for mobile apps. The risk arises when developers store sensitive data, such as usernames and passwords, in the database for caching or later reuse. On a rooted device, the database file is easy to read. In one application we tested, the username and password were stored in plain text.

Prevention: avoid storing sensitive data in the local database. If it must be stored, encrypt it, and keep the key in the platform's secure key store. Never store passwords in a readable form.

Log files

Developers often log the values of fields and variables while debugging, and forget to remove the log statements before release. Device logs can be read by anyone with debugging access to the device, and on older Android versions by other apps. In one application we tested, the username and password were written to the log.

Prevention: remove or disable debug logging in release builds, and never log credentials or other sensitive data.

XML data stores / shared preferences

Shared preferences store data in an XML file inside the app's folder. As with the database, anything stored here can be read on a rooted device. In the same application, the username was stored in the shared preferences file.

Prevention: do not store sensitive data in shared preferences or plain files. If you must, use the platform's encrypted storage.

Keyboard cache

Keyboards remember typed words for auto-correct and suggestions. If a field containing a username or card number allows this, the value is kept in the keyboard's dictionary and can later be suggested or read outside the app. In one application, a username typed a few times was stored in the keyboard cache.

Prevention: disable auto-correct and suggestions on sensitive input fields, and use password-type fields for secrets.

Copy/paste buffer (clipboard)

Anything the user copies goes to the clipboard, which other apps may be able to read. If users can copy a card number or password from your app, it can leak this way.

Prevention: disable copy and cut on sensitive fields, and clear the clipboard where appropriate.

HTML5 data storage

Apps built with web technologies can use browser storage such as localStorage, sessionStorage and IndexedDB. Data in localStorage stays on the device until it is removed, and it is not encrypted. sessionStorage is cleared when the page session ends. Any script running in the page, including an injected one, can read these stores.

Prevention: do not keep sensitive data, such as tokens or personal details, in HTML5 storage.

Browser cookies

Cookies are stored in the browser and sent back to the server with each request. A cookie without the Secure flag can be sent over unencrypted connections, where it can be intercepted. A cookie without HttpOnly can be read by scripts. Cookies are also stored in clear text and can be changed by the user, so the server must never trust their contents blindly.

Prevention: do not store sensitive data in cookies. Set the Secure, HttpOnly and SameSite flags on session cookies, and keep session data on the server.

How Vooki Pro helps

• Vooki Pro tests the web and REST APIs that mobile apps rely on, where much sensitive data is exposed.
• Flags personal data (PII) and API keys in API responses.
• Checks cookie and session security, and sensitive data in cookies.
• Imports captured app traffic as HAR, or requests as cURL, into the API Builder for scanning.

Frequently asked questions

Where should a mobile app store secrets?

In the platform's secure storage (Android Keystore or iOS Keychain), never in plain files, shared preferences or logs.

Does securing the device solve data exposure?

No. The back-end APIs must also return only the data each user needs.

Related: API keys and secrets in front-end code · How to security-test a REST API from OpenAPI or Postman