ABCDEFGHIKLMNOP
1
MASVS-STORAGE
+2 -9 â– â– â– â– â– â– 		REVIEW DONECLOSED FOR COMMENTSOpen Help
2
#MASVS-IDControlL1L2StatusReasoning & New FocusTest CasesRelated Standards
3
4
2.1MSTG-STORAGE-1-System credential storage facilities need to be used to store sensitive data, such as PII, user credentials or cryptographic keys.xxRewordedThis control can become innaccurate depending on the platform (Android vs iOS) and target data. Also system credential storage facilities is not completely accurate since doesn't only hold credentials. You can store, among others, cryptographic keys, authentication tokens and in some cases "arbitrary data" (e.g. a Plist on iOS). Therefore we chose the term "platform keystore", since keystore is a well-known and understood term.

We'll use platform keystore to refer to the Android KeyStore and the iOS KeyChain (see the new MASVS-STORAGE-2).		Current MSTG Test Cases:

https://mobile-security.gitbook.io/mobile-security-testing-guide/?q=MSTG-STORAGE-2
5
2.1MASVS-STORAGE-1+Sensitive data is stored in encrypted form.xxReworded🎯 This requirement is about Sensitive Data in general and the fact that it must be protected (encrypted) regardless of where it's stored.

What's Sensitive Data?

- User Data: PII, location, financial, health, media, app activity, browsing/search, Device IDs, transaction history of paid resources, etc.
- Android Definition
- iOS Definition
- Authentication Data: credentials, tokens, passphrase, PINs, session identifiers, etc.
- Other data: OTA Updates
- Cryptographic Keys (special case, covered by MASVS-STORAGE-2)		Example Tests (non-exhaustive list):

- Check for OS version enforcement (guaranteeing minimum security)
- Check for device-access-security policy enforcement
- e.g. check if the user set a device passcode via isDeviceSecure() on Android and LAContext.canEvaluatePolicy() on iOS. (prev. MSTG-STORAGE-11 -> Now in MASVS-AUTH-2)

- Check for hardcoded sensitive data
 - e.g. cleartext in app package (APK/IPA), app source / compiled binary, libs

- Check for sensitive data not stored in the first place.

- Check if sensitive data is stored encrypted and ensuring exclusive app access.
- in internal storage
 - in scoped storage (external storage, Android)
- in external storage (public folders: SD card, Photos, Downloads, Caches, etc. Android/iOS)
- and verify if explicit user consent is granted (if data is not being encrypted)
- in internal/external caches
- in the KeyChain (iOS only)

- Check if sensitive data is stored ensuring highest available protection.
- Check for bad "encryption" e.g. base64
- Check for highest protection using iOS DataProtection classes (iOS)
- Check for highest protection using iOS KeyChain DataProtection classes (iOS)
- Check for usage of envelope encryption (DEK+KEK) or equivalent
- Check for Android Security Lib usage (EncryptedFile/EncryptedSharedPreferences, Android)
- Check for location & accessibility of DEKs (Data Protection Keys), e.g. in KeyStore/KeyChain

- Check for app-crafted backups
- Check for platform backups (hardening)
- Check for OS version enforcement (guaranteeing minimum security)
- Check for backup prevention (android:allowBackup=false)
- Check for exclusion rules
- Check for backup device conditions (Android)
- Check for custom backup agent (Android)
- Check for sensitive data in final backups
- Check for file operations that reset backup exclusion, don't rely on isExcludedFromBackup (iOS)

- Check for data access best practices
 - SharedPreferences MODE_PRIVATE (Android), DataProtection API (iOS)
- No World-readable/writable data (file permissions)
- Check MASVS-PLATFORM for more

- Check for data supposed to leave the device
 - e.g. password and username stored in cleartext in a cookie

- Check for sensitive data being written to logs:
- Check Android APIs: Log, Logger, Proguard config, System.out.println, System.err or printStackTrace, penaltyLog;
- Check for READ_LOGS permission (Android)
- Check iOS APIs: NSLog, NSAssert, NSCAssert, fprintf, custom functions (Logging, Logfile), crash reporters
- Check for macros (if source available)
- Check all logs' content for sensitive data (e.g. Android system and app-specific logs)


(and more, feel free to suggest ideas)		CWE: CWE-922, CWE-311, CWE-312, CWE-200, CWE-359, CWE-524, CWE-315, CWE-921, CWE-538; CWE-321, CWE-259, CWE-798, CWE-318

CWE (logs): CWE-532, CWE-117, CWE-534

BSI: O.Data_16, O.Cryp_1, O.Data_13

NIAP: FDP_DAR_EXT.1, FDP_DEC_EXT.1.2

ioXt: SD109, SD111

ASVS: C.13, V7.1 (logs)
6
7
8
2.2MSTG-STORAGE-2-No sensitive data should be stored outside of the app container or system credential storage facilities.xxRewordedThe original control is now covered by MASVS-STORAGE-1 and the new one will focus on cryptographic keys rather that "sensitive data" in general.

See more in MSTG-STORAGE-1 above.		Current MSTG Test Cases:

https://mobile-security.gitbook.io/mobile-security-testing-guide/?q=MSTG-STORAGE-2
9
2.2MASVS-STORAGE-2+Cryptographic keys are stored inside the platform keystore or using equivalent protection.xxReworded🎯 This requirement is about Cryptographic Keys specifically.

"Platform keystore": We use platform keystore to refer to the Android KeyStore and the iOS KeyChain.

"Equivalent protection": it is ok to store cryptographic keys outside the platform keystore only if they are protected with "equivalent protection" to that of the platform keystore. For instance, using envelope encryption/key wrapping where keys are encrypted using other keys (called Key Encryption Keys or KEK) living in the platform keystore and never leaving it.

NOTE: This goes inline with the storage portion of Key Management (according to NIST.SP.800-175Br1 5.4.3). The rest is considered part of MASVS-CRYPTO-2 (Key Management).

https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave		Example Tests (non-exhaustive list):

- Check for harcoded keys
- Check for keys in platform keystore (Android KeyStore, iOS KeyChain)
- Check for keys encrypted elsewhere e.g. envelope encryption (DEK+KEK) (considered "equivalent protection"). Also see NIST.SP.800-175Br1 5.3.5 Key Wrapping)
- Check for imported keys
- Check for exported keys
- Check for remote KMS (Key Management System) usage
- e.g. Cognito, Amazon KMS or Azure Key Vault. (considered "equivalent protection")

Hardening: The app can restrict cryptographic key usage according to the specific use case:

- Check Hardware-backed vs StrongBox/SE (max protection, best-effort approach)
- originally mentioned as "tamper-resistant"
- Check key cryptography usage: authorized key algorithm, operations or purposes (encrypt, decrypt, sign,...)
- Check if key accessible from a background process
- Check key availability relative to the lock state of the device, temporal validity interval
- Check key exclusion from backup
- Check key eligibility for restoration to a new device / device binding (originally MSTG-RESILIENCE-10)
- Check if key demands User Presence, application-specific password
- Check for older KeyStore Implementations (e.g. BKS, Android only)

- Check for keys generated and kept in the iOS SE or Android TEE (kSecAttrTokenIDSecureEnclave/setIsStrongBoxBacked)
- Example iOS (proton-mail)
- Example Android (exposure-notifications)
- Check for key attestation (xxx/KeyInfo.isInsideSecurityHardware); include if we consider 8.10 is covered here.

MSTG-RESILIENCE-10: The app implements a 'device binding' functionality using a device fingerprint derived from multiple properties unique to the device.



(and more, feel free to suggest ideas)		CWE: CWE-522

BSI: O.Data_2, O.Cryp_6

NIAP: FCS_STO_EXT.1

ioXt: PC103

ASVS: C.6, 2.9.1

NIST 5.1.7.2
10
11
12
2.3MSTG-STORAGE-3-No sensitive data is written to application logs.xxRewordedRemove the word "application" to include other logs, e.g. "system" logs. Current MSTG Test Cases:

https://mobile-security.gitbook.io/mobile-security-testing-guide/?q=MSTG-STORAGE-3
13
2.3MASVS-STORAGE-3+Sensitive data is never written to logs.xxReworded

We consider this yet another area to look for sensitive data and therefore it's better covered by MASVS-STORAGE-1		Example Tests (non-exhaustive list):

(moved to MASVS-STORAGE-1)		CWE: CWE-532, CWE-117, CWE-534

BSI: O.Data_13

NIAP: FDP_DEC_EXT.1.2

ioXt: SD111

ASVS: V7.1
14
15
16
2.4MSTG-STORAGE-4-No sensitive data is shared with third parties unless it is a necessary part of the architecture.xxTestThis will be a test in MASVS-STORAGE-5 (previously MSTG-STORAGE-12), which is about data privacy.Current MSTG Test Cases:

https://mobile-security.gitbook.io/mobile-security-testing-guide/?q=MSTG-STORAGE-4
17
18
19
20
2.5MSTG-STORAGE-5-The keyboard cache is disabled on text inputs that process sensitive data.xxMovedThis should be part of MASVS-PLATFORM.
21
22
23
24
2.6MSTG-STORAGE-6-No sensitive data is exposed via IPC mechanisms.xxMovedThis should be part of MASVS-PLATFORM.
25
26
27
28
2.7MSTG-STORAGE-7-No sensitive data, such as passwords or pins, is exposed through the user interface.xxMovedThis should be part of MASVS-PLATFORM.
29
30
31
32
2.8MSTG-STORAGE-8-No sensitive data is included in backups generated by the mobile operating system.xMovedThis should be part of MASVS-PLATFORM.
33
34
35
36
2.9MSTG-STORAGE-9-The app removes sensitive data from views when moved to the background.xMovedThis should be part of MASVS-PLATFORM.
37
38
39
40
2.10MSTG-STORAGE-10-The app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.xRewordedRemoved the word "explicitly" which doesn't add value. The MSTG explains what it means that the memory is cleared and goes into detail about the challenges when implementing and when testing that.Current MSTG Test Cases:

https://mobile-security.gitbook.io/mobile-security-testing-guide/?q=MSTG-STORAGE-10
41
2.3MASVS-STORAGE-3+No sensitive data lives longer than necessary, and is cleared after use.

Original proposal: No sensitive data lives in memory longer than necessary, and is cleared after use.		xReworded🎯 The focus changes, it's about preventing sensitive data exposure but not only in memory.

NEW proposal from the comments: if we remove the word "memory" from the requirement we can put the focus on "Data Remanence" anywhere instead of only in the memory. This is very useful to add more tests for privacy. "Memory" simply turns into one are where data should "live shortly".

From Google Play: "data [...] only processed ephemerally. This means the developer accesses and uses your data only when it is stored in memory, and retains the data for no longer than necessary to service a specific request."		Example Tests (non-exhaustive list):

- Check for explicit zeroizing / wiping / clearing of memory (e.g. memset_s(..., 0, ...) on Swift)
- Check for good practices e.g. not using immutable data types, using primitive types, handling data in as few components as possible
- Check for use of memory unsafe APIs (e.g. EditText, SecretKey / BouncyCastle.Cipher on Android)
- Check for use of memory safe APIs (e.g. CryptoKit.SymmetricKey on iOS)
- Check if sensitive information is only decrypted when it's necessary for it to be used in cleartext (actually STORAGE-1?)
- Check if sensitive information is/remains encrypted before being put to memory (actually STORAGE-1?)
- Check if the app’s local storage is wiped after an excessive number of failed authentication attempts. (prev. MSTG-STORAGE-15, related to MASVS-AUTH) * if we remove "memory" from the control to cover for a more generic "data wipe" to prevent leakage.

(and more, feel free to suggest ideas)		CWE: CWE-459, CWE-226, CWE-316

BSI: O.Plat_14

NIAP: N/A

ioXt: N/A

ASVS: 8.3.6
42
43
44
2.11MSTG-STORAGE-11-The app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode.xTestThis will be a test in MASVS-STORAGE-1. If no passcode is set MASVS-STORAGE-1 should fail because data cannot be encrypted with sufficient protection.Current MSTG Test Cases:

https://mobile-security.gitbook.io/mobile-security-testing-guide/?q=MSTG-STORAGE-11
45
xTest
46
47
48
2.12MSTG-STORAGE-12-The app educates the user about the types of personally identifiable information processed, as well as security best practices the user should follow in using the app.xxRemovedReworded for simplicity and to add some abstraction. There's much more than "user education" when testing this requirement and that will be reflected in the MSTG and will change and grow along with the latest platform improvements.Current MSTG Test Cases:

https://mobile-security.gitbook.io/mobile-security-testing-guide/?q=MSTG-STORAGE-12
49
2.4MASVS-STORAGE-4+The app follows privacy best practices when processing sensitive user data.xxRemoved🎯 This control acklowledges the importance of Data Privacy.

Testing privacy is a complex task and the platforms (Android and iOS) improve quickly. This control should provide enough abstraction to cover for that quick evolution and leaves the details to the MSTG which will grow on a more agile fashion.

"Best practices" will be detailed in the MSTG offering a testing baseline for many different privacy aspects beyond user education.		Example Tests (non-exhaustive list):

- Check for Privacy Nutrition Labels (APIs will be available)
- Check for Broad consent via PLATFORM-1 (permissions)
- Check for Specific consent dialogs before data is tx
- Check for device-specific identifiers (e.g. IMEIs, SSettings.Secure.ANDROID) being used (UUIDs/cookies linked to user data) and non-resettable device identifiers
- Check for 3rd party data share / 1st party data collection: minimum necessary to provide service.
- Check for privacy policy dialog and privacy policy in-app review
- Check for Data Access Auditing

(and more, feel free to suggest ideas)		CWE: CWE-315

BSI: N/A

NIAP: FPR_ANO_EXT.1

ioXt: N/A

ASVS: N/A

https://owasp.org/www-project-top-10-privacy-risks/
https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html
50
51
52
2.13MSTG-STORAGE-13-No sensitive data should be stored locally on the mobile device. Instead, data should be retrieved from a remote endpoint when needed and only be kept in memory.xRemovedCovered by MASVS-ARCH. It's an architectural decision. The app devs. might decide to:

A) Exclusively retrieve data from a remote endpoint and make it only reside in the app volatile memory.
B) or store sensitive data only locally encrypted and never in a remote endpoint.
C) Hybrid (most common)

Regardless of the option, the MASVS-STORAGE protects local data at rest which is stored in the mobile device.		Current MSTG Test Cases:

N/A
53
xRemoved
54
55
56
57
2.14MSTG-STORAGE-14-If sensitive data is still required to be stored locally, it should be encrypted using a key derived from hardware backed storage which requires authentication.xTestThis control has 3 different aspects which are already covered in other controls (or by their corresponding tests):

1) encrypt locally stored data with a key (stored securely): about encrypting sensitive data using a key from the platform kexstore or using envelope encryption DEK+KEK -> covered by MASVS-STORAGE-1.

2) the key is derived from hardware backed storage: about ensuring that the DEK (or the corresponding KEK) was generated in hardware-backed storage (TEE/SE). -> covered by MASVS-STORAGE-2.

3) the key must require authentication: will be a test in MASVS-CRYPTO-3 which is about Key Management according to NIST.SP.800-175B.		Current MSTG Test Cases:

N/A
58
xTest
59
60
61
62
2.15MSTG-STORAGE-15-The app’s local storage should be wiped after an excessive number of failed authentication attempts.xRemovedThis is covered by MASVS-STORAGE-1: we consider that properly encrypting data means that even if it's not deleted on uninstall/after excessive auth-fails it will be safe.Current MSTG Test Cases:

N/A
63
xRemoved
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100