Home / Attacks & tests / Application Local Storage Flaws Testing for Mobile Applications
6 test cases
Application Local Storage Flaws Testing for Mobile Applications
Local storage testing examines what the application leaves on the device and who else can read it. The platform's sandbox is a real boundary, but it protects only what is placed inside it, and only against an attacker who has not obtained elevated privileges.
What an attacker is trying to achieve
The attacker has the device, or an application on it. They want whatever the target application wrote down: session tokens that outlive the session, personal data cached for convenience, keys stored beside the data they protect, and anything written outside the sandbox where any other application can read it.
Test cases
6 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
AND-STOR-01 Hidden Secrets in the Code
Objective — Determine whether keys, credentials or other secrets are embedded in the package, where every user of the application also holds them.
How it is tested — Search the decompiled source, resources, assets, configuration and native libraries for key material, credentials, tokens and endpoints requiring authentication. Include values assembled at runtime from parts, and values obscured by encoding or a bundled cipher, since the key for that cipher is necessarily present too. Establish for each secret found what it authorises and whether it is shared across all installations.
Prerequisites — The decompiled package including native libraries; the ability to run the application to observe runtime assembly of obscured values.
Indicators — A credential or key recoverable from the package; a value obscured rather than protected; one secret shared by every installation; a secret that authorises a server-side operation.
Coverage — MASVS-STORAGE-1MASVS-CRYPTO-2CWE-798CWE-321
Depth — Hybrid Pattern scanning finds plain secrets; recovering ones assembled at runtime requires following the code.
AND-STOR-02 Sensitive Data on Shared Storage
Objective — Determine whether the application writes data outside its private sandbox, where other applications and the user can read it.
How it is tested — Drive every workflow that produces a file — downloads, exports, attachments, caches, camera and document capture, backups — and record where each artefact lands. Establish which are written to shared locations, what they contain, and whether they persist after the workflow completes or the user signs out. Test whether the application reads back from shared locations material it then trusts.
Prerequisites — A device with filesystem access; the ability to enumerate shared storage before and after each workflow; an account with representative data.
Indicators — Personal or session data written to shared storage; temporary artefacts persisting after use; data surviving sign-out; the application trusting a file another application could have replaced.
Coverage — MASVS-STORAGE-1MASVS-STORAGE-2CWE-922CWE-276
Depth — Manual Requires exercising each workflow and diffing the filesystem around it.
AND-STOR-03 Cryptographic Storage Strength
Objective — Determine whether data the application encrypts before storing is genuinely protected, or whether the key is recoverable by anyone holding the device.
How it is tested — Identify what is encrypted at rest and trace how the key is derived and held. Establish whether it comes from the platform's hardware-backed key store, from a user secret, or from something present in the package. Where a passphrase is involved, establish the derivation and its work factor. Attempt to decrypt stored data using only material recoverable from the device and package, which is the attacker's actual position.
Prerequisites — A device with access to application storage and the key store; the decompiled package; sample encrypted data produced by real use.
Indicators — Stored data decryptable with material from the device alone; a key derived from a device identifier or a package constant; a weak or absent derivation function; keys held outside hardware-backed storage without cause.
Coverage — MASVS-CRYPTO-1MASVS-CRYPTO-2CWE-311CWE-522
Depth — Manual The test is whether the tester can decrypt from the attacker's position, which requires reconstructing the key path.
AND-STOR-04 Content Provider Access Permissions
Objective — Determine whether data-sharing components expose the application's data to other applications on the device.
How it is tested — Enumerate the providers declared in the manifest and their export status, permissions and path-level rules. From a separate unprivileged application, query each reachable provider and attempt to read, insert, update and delete. Test path permissions individually, since a provider protected overall is frequently reachable through a specific path. Establish whether granted temporary access can be retained or widened.
Prerequisites — The manifest; a device; a separate test application holding no relevant permissions; the provider authorities recovered from the package.
Indicators — A provider readable or writable by an unprivileged application; a path rule weaker than the component's own protection; temporary access outliving the grant.
Coverage — MASVS-PLATFORM-1MASVS-STORAGE-1CWE-926CWE-285
Depth — Manual Confirmation requires a second application on the device acting as the attacker would.
AND-STOR-05 Content Provider SQL Injection
Objective — Determine whether query parameters passed to a data-sharing component reach the underlying database as syntax, allowing another application to read beyond what the provider intends to expose.
How it is tested — For each reachable provider, submit selection clauses, projections and sort orders containing query syntax rather than values. Establish whether the provider constrains the projection or passes it through, since an unconstrained projection commonly permits reading columns and tables the provider was never meant to expose. Test path segments used as identifiers as well as explicit parameters.
Prerequisites — A reachable provider; a test application able to issue arbitrary queries; the schema inferred from the decompiled package.
Indicators — Query syntax altering the result set; a projection returning columns outside the intended set; database errors surfacing to the calling application; data from another table returned.
Coverage — MASVS-PLATFORM-1MASVS-CODE-4CWE-89CWE-926
Depth — Manual Requires a caller application and knowledge of the underlying schema.
AND-STOR-06 Privacy and Metadata Leaks
Objective — Determine whether the application retains or transmits more personal data than its function requires, including metadata attached to content the user supplies.
How it is tested — Inventory what the application collects, stores and sends, and compare against the function each item supports and the disclosure the user was given. Examine media and documents the application uploads for retained location, device and authorship metadata. Establish whether identifiers are persistent across reinstalls, and whether data is shared with bundled analytics or advertising components without a corresponding disclosure.
Prerequisites — A proxy capturing all outbound traffic including third-party destinations; the application's own privacy disclosure for comparison; sample media carrying metadata.
Indicators — Data collected beyond the stated purpose; metadata transmitted with uploaded content; a persistent identifier surviving reinstall; personal data sent to a third party without disclosure.
Coverage — MASVS-PRIVACY-1MASVS-PRIVACY-3CWE-359CWE-200
Depth — Manual The comparison is against the stated purpose, which has to be read and interpreted rather than detected.
What we need from you
A device or emulator on which the application's private storage can be inspected, which generally means elevated privileges; the ability to drive every workflow that persists data; and a second application, or shell access, to test what is readable from outside the sandbox.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- MASVS-STORAGE-1 — The app securely stores sensitive data.
- MASVS-CRYPTO-2 — The app performs key management according to industry best practices.
- CWE-798 — Use of Hard-coded Credentials
- CWE-321 — Use of Hard-coded Cryptographic Key
- MASVS-STORAGE-2 — The app prevents leakage of sensitive data.
- CWE-922 — Insecure Storage of Sensitive Information
- CWE-276 — Incorrect Default Permissions
- MASVS-CRYPTO-1 — The app employs current strong cryptography and uses it according to industry best practices.
- CWE-311 — Missing Encryption of Sensitive Data
- CWE-522 — Insufficiently Protected Credentials
- MASVS-PLATFORM-1 — The app uses IPC mechanisms securely.
- CWE-926 — Improper Export of Android Application Components
- CWE-285 — Improper Authorization
- MASVS-CODE-4 — The app validates and sanitizes all untrusted inputs.
- CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
- MASVS-PRIVACY-1 — The app minimizes access to sensitive data and resources.
- MASVS-PRIVACY-3 — The app is transparent about data collection and usage.
- CWE-359 — Exposure of Private Personal Information to an Unauthorized Actor
- CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.