How to Test OWASP Mobile M9:2024 Insecure Data Storage

OWASP Mobile M9:2024 Insecure Data Storage covers any case where a mobile app writes sensitive data to a location an attacker can read without breaking encryption — SharedPreferences files, SQLite databases, cache directories, crash logs, or unencrypted backups. Testing it means pulling the app's local storage off a rooted or jailbroken device and inspecting every file the app writes, not just running a static scanner against the binary. The hidden cost most teams miss: even apps that encrypt data in transit routinely leave tokens, PII, or session data sitting in plaintext at rest, which turns a stolen or lost device into a full account compromise.

TL;DR

• Testing OWASP Mobile M9:2024 Insecure Data Storage requires manual extraction of local storage on a rooted or jailbroken device, not just static analysis.
• Common leak points are SharedPreferences/NSUserDefaults, SQLite and Realm databases, cache files, application logs, clipboard data, and unencrypted backups.
• Encryption in transit does not fix M9 findings — data at rest needs its own review of keystore usage, key derivation, and file permissions.
• PCI DSS, HIPAA, SOC 2, and MAS TRM assessors all expect evidence that data-at-rest controls on mobile clients were independently tested, not just documented.
• Manual penetration testing finds business-logic storage flaws automated mobile scanners miss, particularly around session persistence and third-party SDK data caching.

Why This Matters

Insecure data storage is not a theoretical finding — it is the difference between a lost phone being an inconvenience and a lost phone being a data breach notification. For fintech, healthcare, and SaaS apps handling regulated data, an M9 finding on a production build can trigger audit failures under PCI DSS, HIPAA, or SOC 2, because reviewers now expect mobile clients to be tested with the same rigor as web applications.

AppSecure Security treats OWASP Mobile M9:2024 as a manual, device-level testing category, not a checklist item satisfied by a source code linter. The rest of this guide walks through the testing methodology, the storage locations that matter most, the compliance mapping, and the checklist a security team can hand to a mobile engineering lead.

How to Test OWASP Mobile M9:2024 Insecure Data Storage

Testing M9 follows a repeatable sequence. Each step should produce evidence — a screenshot, a file dump, or a database export — that a developer can use to reproduce and fix the issue.

1. Scope the build. Confirm the app version, platform (iOS/Android), backend environment, and whether the test covers a production or staging build. Insecure storage findings differ significantly between debug and release builds.
2. Root or jailbreak a test device. Local storage on a stock device is sandboxed. A rooted Android device or a jailbroken iOS device (or a simulator with filesystem access) is required to read the app's private data directory.
3. Trigger realistic app states. Log in, complete a transaction, upload a document, background the app, and force a crash. Many storage leaks only appear after specific user flows, not on first launch.
4. Pull and inspect the data directory. Extract /data/data/<package> on Android or the app container on iOS. Search every file — not just obvious ones named "cache" or "prefs" — for tokens, PII, card data, or health records.
5. Query local databases directly. Open SQLite and Realm files with a database browser outside the app. Confirm whether sensitive fields are encrypted at the column level or stored as plaintext.
6. Review logs and crash reports. Check logcat output, console logs, and crash reporting SDK payloads for leaked credentials or session tokens.
7. Inspect backups. Test whether iOS iCloud/iTunes backups or Android auto-backup include the app's sensitive files, and whether that inclusion was intentional.
8. Validate remediation. After the development team applies fixes, repeat steps 3-7 on the patched build to confirm the data no longer persists in plaintext.

This sequence mirrors the manual workflow AppSecure Security uses when conducting a mobile app penetration test — extraction and direct inspection first, tooling second.

Where Mobile Apps Leak Data at Rest

M9 findings cluster around six storage locations. Each requires a different extraction technique.

SharedPreferences and NSUserDefaults

Android's SharedPreferences and iOS's NSUserDefaults are key-value stores meant for non-sensitive configuration data, but developers routinely stash auth tokens, PINs, and user profile data here because the API is convenient. These files are XML or plist text — readable with a text editor the moment the directory is extracted.

SQLite and Realm Databases

Local databases cache API responses, offline data, and user records. Testing means opening the .db or .realm file with a standalone browser and checking whether sensitive columns are stored in cleartext or protected with field-level encryption tied to a hardware-backed key.

Cache and Temporary Files

Image caches, downloaded PDFs, and API response caches often persist far longer than the session that created them. A cached bank statement or ID document scan in a world-readable cache directory is a common finding in fintech and healthcare apps.

Application Logs

Verbose logging left enabled in production builds writes request/response bodies, including auth headers and PII, straight to the device log. This is one of the fastest wins for a tester with device shell access.

Clipboard Data

Copy-to-clipboard features for OTPs, card numbers, or passwords leave that data readable by any other app with clipboard access on older OS versions, and by clipboard-monitoring malware.

Backups and Screenshots

iOS backgrounding snapshots and Android/iOS cloud backups can capture sensitive screens or unencrypted files if the app has not explicitly excluded them. Testing this requires reviewing the backup manifest, not just the live app state.

Why Insecure Data Storage Risk Varies by App

• Platform defaults — iOS Keychain and Android Keystore provide hardware-backed storage, but only when developers actually use them instead of defaulting to plain files.
• Third-party SDKs — analytics, crash reporting, and ad SDKs frequently cache request payloads independently of the app's own storage logic, creating leaks the app team never coded directly.
• Offline-first architecture — apps built for offline use cache more data locally by design, expanding the attack surface for M9 findings.
• Backup configuration — whether allowBackup is set on Android or backup exclusion is configured on iOS materially changes exposure.
• Root/jailbreak detection maturity — apps with weak or absent root detection make extraction and analysis trivial for an attacker with physical device access.
• Regulatory data class — apps handling cardholder data, health records, or financial credentials face stricter expectations for what "insecure" means, even for short-lived cache files.

Compliance Mapping for M9 Findings

PCI DSS

• What It Requires: Cardholder data must not be stored unencrypted, including on mobile clients that cache payment flows
• Testing Implication: Testers must confirm no PAN, CVV, or token data persists in SharedPreferences, logs, or cache

HIPAA

• What It Requires: Protected health information must be safeguarded against unauthorized disclosure at rest
• Testing Implication: Mobile storage review must cover local databases and cached documents on patient-facing apps

SOC 2

• What It Requires: Confidentiality criteria require documented and tested controls over data at rest
• Testing Implication: Auditors expect evidence of a manual mobile storage assessment, not just a policy statement

MAS TRM

• What It Requires: Financial institutions must assess technology risk across all client-facing channels, including mobile
• Testing Implication: Storage findings on banking apps must be remediated and retested before go-live

GDPR

• What It Requires: Personal data must be protected using appropriate technical measures
• Testing Implication: Plaintext storage of EU user data on-device is treated as inadequate technical measure

These mappings are why mobile testing scope for regulated clients increasingly mirrors what AppSecure Security runs for mobile app penetration testing for banking apps — the storage review is not optional, it is an audit deliverable.

Manual Testing vs Automated Scanning for Insecure Storage

Static analysis tools flag obvious patterns — hardcoded keys, Log.d() calls, disabled backup flags. They miss what actually causes breaches: data written conditionally during a specific business flow, third-party SDK caching behavior invisible in the app's own source, and files that only appear after a crash or a background transition.

Manual testing catches these because a tester interacts with the app the way a real user or attacker would, then inspects the resulting filesystem state directly. A scanner reading source code cannot see what a debug build writes to disk after a payment is declined or a session times out mid-transaction — a human tester triggering that exact flow can.

OWASP Mobile M9 Insecure Data Storage Testing Checklist

• Confirm SharedPreferences/NSUserDefaults contain no tokens, PINs, or PII
• Confirm SQLite/Realm databases use field-level encryption for sensitive columns
• Confirm production builds have verbose logging disabled
• Confirm cache directories are cleared or encrypted after session end
• Confirm clipboard use is minimized for OTPs, passwords, and card data
• Confirm backup exclusion is configured for sensitive files on both platforms
• Confirm Keychain/Keystore is used for credentials instead of flat files
• Confirm crash reporting SDKs are not capturing request payloads
• Confirm findings are retested on the patched build before closure

Related Questions

Is M9 the Same as Encryption at Rest?

M9 insecure data storage is broader than encryption at rest — encryption is one control among several, and a database can be technically "encrypted" while still failing M9 if the key is stored alongside the data or derived predictably. Testing must verify key management, not just the presence of an encryption call.

How Does M9 Differ From M5 Insecure Communication?

M9 covers data sitting on the device after it has been received or before it is sent, while OWASP Mobile M5 Insecure Communication covers data moving between the app and backend. An app can pass every transport-layer test and still fail M9 if it writes the same data to an unencrypted cache file immediately after receiving it.

Can Root or Jailbreak Detection Alone Fix M9 Findings?

Root and jailbreak detection alone does not fix M9 findings because it can be bypassed with widely available hooking frameworks, and it does nothing to protect data on a device that is rooted for legitimate reasons. Storage-layer controls — encryption, minimal retention, and backup exclusion — are the actual fix; detection is a secondary defense at best.

FAQ

What is OWASP Mobile M9:2024 Insecure Data Storage?

OWASP Mobile M9:2024 Insecure Data Storage is a category in the OWASP Mobile Top 10 covering sensitive data an app writes to device storage in a way that is readable without breaking encryption. It includes SharedPreferences, local databases, cache files, logs, and backups.

How do you test for insecure mobile data storage?

Testing insecure mobile data storage requires extracting the app's private data directory from a rooted Android device or jailbroken iOS device, then inspecting every file for tokens, PII, or financial data. Automated scanners alone miss storage that only appears during specific app flows.

Do I need a rooted device to test M9?

Yes, a rooted Android device or jailbroken iOS device is required to access the app's sandboxed private storage directory. Testing on a stock, unmodified device cannot reach the files where most M9 findings live.

Does encrypting data in transit prevent M9 findings?

No, encrypting data in transit only protects data while it moves between the app and the backend. M9 findings occur after data lands on the device, so transport encryption has no effect on plaintext files stored locally.

What is the most common M9 finding in production apps?

The most common M9 finding is authentication tokens or session data stored in SharedPreferences or NSUserDefaults instead of the platform Keystore or Keychain. This is frequent because the key-value API is easier to use than hardware-backed storage.

Does PCI DSS require mobile app storage testing?

PCI DSS requires that cardholder data not be stored unencrypted anywhere in the environment, including mobile clients that process or cache payment data. Assessors expect evidence that mobile storage was independently tested, not just documented in a policy.

How is M9 different from insecure authentication (M3)?

M9 covers where data is stored after authentication succeeds, while OWASP Mobile M3 Insecure Authentication and Authorization covers how a user or session is verified. A token can be issued securely under M3 controls and still be stored insecurely under M9.

Can third-party SDKs cause M9 findings even if the app code is clean?

Yes, analytics, crash reporting, and advertising SDKs frequently cache request payloads or user identifiers independently of the app's own storage logic. Testing must include SDK-generated files, not just files the development team wrote directly.

How often should mobile apps be retested for insecure data storage?

Mobile apps handling regulated data should be retested for insecure data storage after any major release that changes local caching, offline functionality, or third-party SDK versions. Annual testing alone misses issues introduced between release cycles.

One Last Thing

The M9 finding teams overlook most often is not in the app's own code — it is in a crash reporting or analytics SDK that captured a full API request, tokens included, and cached it to disk before ever transmitting it. Reviewing every third-party SDK's local cache behavior, not just the app's own storage calls, closes gaps that a source code review alone will not catch.

Get your mobile app tested for M9

Manual, device-level testing for OWASP Mobile Top 10 findings.

Talk to AppSecure

Related Guides

• How to Test OWASP Mobile M1 Improper Credential Usage
• Mobile App Penetration Testing for Banking Apps