The fundamental problem with mobile storage
Unlike a web application where sensitive data stays server-side, a mobile application often stores information locally: authentication tokens, user preferences, cached data, downloaded files. Every piece of data stored on the device is potentially accessible to an attacker with physical access or who exploits another vulnerability.
Android: storage pitfalls
Plaintext SharedPreferences
SharedPreferences are the most commonly used key-value storage on Android. By default, they're stored as unencrypted XML in /data/data/[package]/shared_prefs/. On a rooted device, these files are readable. We regularly find JWT tokens, API keys, and even passwords in these files.
Solution: use EncryptedSharedPreferences from the Jetpack Security library. Encryption is transparent to the developer.
Unencrypted SQLite databases
SQLite is used for structured storage. Without an encryption library like SQLCipher, databases are readable in plaintext. An adb pull on a rooted device or an unencrypted backup is enough to extract all the data.
Application logs
Log.d("auth", "Token: " + token) in debug mode that stays in production. Logs are accessible via adb logcat and can contain tokens, user data, or URLs with sensitive parameters.
WebView cache
WebViews cache HTML, cookies, and form data. If a WebView displays sensitive data, it can persist in the cache even after logout.
iOS: false friends of security
NSUserDefaults
The iOS equivalent of SharedPreferences. Stores in plaintext in a plist. This is not a secure location despite what many developers think. The data is in iTunes backups and accessible with forensics tools.
Misconfigured Keychain
The iOS Keychain is secure by design but its protection level depends on configuration. The kSecAttrAccessibleAlways attribute makes data accessible even when the device is locked. The correct attribute for most cases is kSecAttrAccessibleWhenUnlockedThisDeviceOnly.
Clipboard
The iOS clipboard is shared between all applications. If the user copies a password or 2FA code, any background application can read it. Since iOS 16, the user is warned but access remains possible.
Background snapshots
When an application goes to the background, iOS captures a screenshot for the transition animation. If the screen displays sensitive data (bank balance, medical information), this image is stored on the device.
What we find in audits
In our analyses, we frequently find:
Ground rules
Request a free CleanIssue diagnostic to audit your mobile application's local storage.
Related articles
Three adjacent analyses to keep exploring the same attack surface.
Mobile security: OWASP MASVS for iOS and Android
The OWASP MASVS reference decoded: verification categories for securing your iOS and Android mobile applications.
Chatbot Leaks: 5 Ways Your Customer-Facing AI Bot Exposes Your Data
Enterprise AI chatbots leak data in 5 different ways. Identification of vectors and concrete solutions.
Cryptography in practice: mistakes that make your encryption useless
Common cryptographic mistakes in applications: obsolete algorithms, poorly managed keys, and inappropriate encryption modes.
Sources
Editorial analysis based on official vendor, project, and regulator documentation.
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.