Chapter 1 of 8 · 6 checks · 4 min

Data storage (MASVS-STORAGE)

Checks that secrets never ship in the app, and that sensitive data kept on the device stays in the app sandbox, protected by platform key storage.

Show

No API secrets, private keys or admin credentials are compiled into the appMust
Why it matters and how to check
Any string in an APK, AAB or IPA can be extracted with free tools, and obfuscation only slows that down. Keys for payment providers, AI APIs, email services or your own admin endpoints must stay on your server; the app calls your backend, which calls the provider. Android's guidance also says not to commit API keys to source control.
To verify: build a release package, unzip it (an IPA is a zip as well) and search every file for known key prefixes and the values from your .env with grep -r or strings. Search the repository history too. Publishable keys meant for clients are fine only if their real protection, such as referrer limits or server rules, is configured.
Example
Shell
unzip -q app-release.apk -d /tmp/apk grep -rEo '(sk_live_|AKIA|AIza|ghp_)[A-Za-z0-9_-]{8,}' /tmp/apk | sort -u strings /tmp/apk/classes*.dex | grep -i 'secret\|api_key' | head
Tokens and sensitive data are stored with Keychain or Keystore-backed encryptionMust
Why it matters and how to check
Plain SharedPreferences, UserDefaults, AsyncStorage or a SQLite file can be read from a backup, a rooted or jailbroken device, or a forensic image. Store session tokens and other sensitive values in the iOS Keychain, or on Android encrypt them with a key held in the Android Keystore, which the Android docs recommend for long-term key storage. Cross-platform libraries such as flutter_secure_storage or expo-secure-store wrap these.
To verify: on an emulator or test device, use the app, then pull its data directory (adb shell run-as com.example.app ls -R on a debug build, or the simulator's container on iOS). Search the files for your token, the user's email and any personal data. None should appear in plain text.
Release builds do not log tokens, personal data or request bodiesMust
Why it matters and how to check
Android's guidance warns that logs can be read by apps with the READ_LOGS permission and says not to log personal data. Debug logging of whole HTTP requests and responses copies tokens and user data into device logs and crash reports.
To verify: install a release build, connect the device, and run adb logcat (Android) or watch the Console app (iOS) while you sign in and use the main features. Search the output for the token, email and phone number. Wrap logging in a helper that is stripped or silenced in release builds, and turn off verbose HTTP logging interceptors outside debug.
Sensitive files are never written to shared or external storageShould
Why it matters and how to check
Android's guidance says files on external storage are globally readable and writable, so only non-sensitive data belongs there, and data read back from it should be treated as untrusted. The app's internal storage is private to the app by default. On iOS, files shared through app groups or the Files app are similarly visible to other code.
To verify: search the code for getExternalStorage, Environment.DIRECTORY_, MediaStore and shared container paths. For each, confirm the data is not sensitive (exports the user asked for are fine). Check that downloaded documents with personal data are written to internal storage and deleted when no longer needed.
Sensitive screens and data are excluded from backups and app switcher snapshotsShould
Why it matters and how to check
Device backups can copy app data to a computer or the cloud, and both platforms keep a screenshot of the last screen for the app switcher. For banking, health or other sensitive apps, that snapshot can show a balance or a document.
To verify: on Android, read the android:allowBackup and dataExtractionRules settings in the manifest and exclude files holding tokens or personal data. Check that sensitive screens set FLAG_SECURE. On iOS, open a sensitive screen, go to the app switcher, and check whether the content is visible; apps usually cover it when moving to the background. Mark files that should not be backed up with the platform's exclude-from-backup attribute.
Passwords and codes are not left on the clipboard or learned by the keyboardNice to have
Why it matters and how to check
Other apps can read the clipboard, and keyboards may store typed words for suggestions. Password and one-time code fields should be marked as secure inputs so the system keyboard does not learn them, and the app should avoid copying secrets to the clipboard without the user asking.
To verify: check that password fields use secure text entry (secureTextEntry, obscureText, or inputType="textPassword"). Search for clipboard writes in the code and confirm none copy tokens, recovery codes or personal data automatically.