OWASP Mobile Application Security Checklist

Based on the OWASP Mobile Application Security Verification Standard

General Testing Information

MASVS VERSION
Online version of the MASVS
MSTG Version:
Online version of the MSTG:
The two rows above are used to construct the base for all hyperlinks in the Android and iOS ch
Adjust to your specific use case to update all hyperlinks to a specific version of the MSTG
Client Name:
Test Location:
Start Date:
Closing Date:
Name of Tester:
Testing Scope

Verification Level

Testing information Android

Application Name:
Google Play Store Link
Filename
Version

SHA256 Hash of APK

(Can be obtained by using
shasum, openssl or
sha256sum)

Testing information iOS

Application Name:
App Store Link
Filename
Version

SHA256 Hash of IPA

(Can be obtained by using
shasum, openssl or
sha256sum)

Client Representatives and Contact Information

Name:
Org:
Title:
Phone:
E-mail:

Name:
Org:
Title:
Phone:
E-mail:
 e Application Security Checklist

OWASP Mobile Application Security Verification Standard

formation
1.2
https://github.com/OWASP/owasp-masvs/blob/1.2/Document/
1.1.3-excel
https://github.com/OWASP/owasp-mstg/blob/1.1.3-excel/Document/
e are used to construct the base for all hyperlinks in the Android and iOS checklists.
cific use case to update all hyperlinks to a specific version of the MSTG

All available functions within the App <AppName>.

After consultation with <Customer> it was decided that only Level 1 requrirements are applicable to
<AppName>.

n Android

ives and Contact Information

Mobile Application Security Requirements - Android

ID MSTG-ID
V2
2.1 MSTG-STORAGE‑1

2.2 MSTG-STORAGE‑2

2.3 MSTG-STORAGE‑3

2.4 MSTG-STORAGE‑4

2.5 MSTG-STORAGE‑5

2.6 MSTG-STORAGE‑6

2.7 MSTG-STORAGE‑7

2.8 MSTG-STORAGE‑8

2.9 MSTG-STORAGE‑9

2.10 MSTG-STORAGE‑10

2.11 MSTG-STORAGE‑11

2.12 MSTG-STORAGE‑12

2.13 MSTG-STORAGE‑13

2.14 MSTG-STORAGE‑14

2.15 MSTG-STORAGE‑15

V3
3.1 MSTG‑CRYPTO‑1

3.2 MSTG‑CRYPTO‑2

3.3 MSTG‑CRYPTO‑3

3.4 MSTG‑CRYPTO‑4
3.5 MSTG‑CRYPTO‑5

3.6 MSTG‑CRYPTO‑6

V4
4.1 MSTG-AUTH-1

4.2 MSTG-AUTH-2

4.3 MSTG-AUTH-3

4.4 MSTG-AUTH-4

4.5 MSTG-AUTH-5

4.6 MSTG-AUTH-6

4.7 MSTG-AUTH-7

4.8 MSTG-AUTH-8

4.9 MSTG-AUTH-9

4.10 MSTG-AUTH-10

4.11 MSTG-AUTH-11

4.12 MSTG-AUTH-12

V5
5.1 MSTG-NETWORK-1

5.2 MSTG-NETWORK-2

5.3 MSTG-NETWORK-3

5.4 MSTG-NETWORK-4

5.5 MSTG-NETWORK-5

5.6 MSTG-NETWORK-6

V6
6.1 MSTG-PLATFORM-1
6.2 MSTG-PLATFORM-2

6.3 MSTG-PLATFORM-3

6.4 MSTG-PLATFORM-4

6.5 MSTG-PLATFORM-5

6.6 MSTG-PLATFORM-6

6.7 MSTG-PLATFORM-7

6.8 MSTG-PLATFORM-8

6.9 MSTG-PLATFORM-9

6.10 MSTG-PLATFORM-10

6.11 MSTG-PLATFORM-11

V7
7.1 MSTG-CODE-1

7.2 MSTG-CODE-2

7.3 MSTG-CODE-3

7.4 MSTG-CODE-4

7.5 MSTG-CODE-5

7.6 MSTG-CODE-6

7.7 MSTG-CODE-7

7.8 MSTG-CODE-8

7.9 MSTG-CODE-9

7.10 MSTG-CODE-10
Legend
Symbol
Pass
Fail
N/A
on Security Requirements - Android

Detailed Verification Requirement

Data Storage and Privacy
System credential storage facilities need to be used to store sensitive data, such as PII, user credentials
or cryptographic keys.
No sensitive data should be stored outside of the app container or system credential storage facilities.

No sensitive data is written to application logs.

No sensitive data is shared with third parties unless it is a necessary part of the architecture.

The keyboard cache is disabled on text inputs that process sensitive data.

No sensitive data is exposed via IPC mechanisms.

No sensitive data, such as passwords or pins, is exposed through the user interface.

No sensitive data is included in backups generated by the mobile operating system.

The app removes sensitive data from views when moved to the background.

The app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly
after use.
The app enforces a minimum device-access-security policy, such as requiring the user to set a device
passcode.
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.
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.
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.
The app’s local storage should be wiped after an excessive number of failed authentication attempts.

Cryptography
The app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption.

The app uses proven implementations of cryptographic primitives.

The app uses cryptographic primitives that are appropriate for the particular use-case, configured with
parameters that adhere to industry best practices.
The app does not use cryptographic protocols or algorithms that are widely considered deprecated for
security purposes.
The app doesn't re-use the same cryptographic key for multiple purposes.

All random values are generated using a sufficiently secure random number generator.

Authentication and Session Management

If the app provides users access to a remote service, some form of authentication, such as
username/password authentication, is performed at the remote endpoint.
If stateful session management is used, the remote endpoint uses randomly generated session
identifiers to authenticate client requests without sending the user's credentials.
If stateless token-based authentication is used, the server provides a token that has been signed using a
secure algorithm.
The remote endpoint terminates the existing session when the user logs out.

A password policy exists and is enforced at the remote endpoint.

The remote endpoint implements a mechanism to protect against the submission of credentials an
excessive number of times.
Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens
expire.
Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or
"false"). Instead, it is based on unlocking the keychain/keystore.
A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently
enforced.
Sensitive transactions require step-up authentication.

The app informs the user of all sensitive activities with their account. Users are able to view a list of
devices, view contextual information (IP address, location, etc.), and to block specific devices.
Authorization models should be defined and enforced at the remote endpoint.

Network Communication
Data is encrypted on the network using TLS. The secure channel is used consistently throughout the app.

The TLS settings are in line with current best practices, or as close as possible if the mobile operating
system does not support the recommended standards.
The app verifies the X.509 certificate of the remote endpoint when the secure channel is established.
Only certificates signed by a trusted CA are accepted.
The app either uses its own certificate store, or pins the endpoint certificate or public key, and
subsequently does not establish connections with endpoints that offer a different certificate or key, even
if signed by a trusted CA.

The app doesn't rely on a single insecure communication channel (email or SMS) for critical operations,
such as enrollments and account recovery.
The app only depends on up-to-date connectivity and security libraries.

Platform Interaction
The app only requests the minimum set of permissions necessary.
All inputs from external sources and the user are validated and if necessary sanitized. This includes data
received via the UI, IPC mechanisms such as intents, custom URLs, and network sources.
The app does not export sensitive functionality via custom URL schemes, unless these mechanisms are
properly protected.
The app does not export sensitive functionality through IPC facilities, unless these mechanisms are
properly protected.
JavaScript is disabled in WebViews unless explicitly required.

WebViews are configured to allow only the minimum set of protocol handlers required (ideally, only
https is supported). Potentially dangerous handlers, such as file, tel and app-id, are disabled.
If native methods of the app are exposed to a WebView, verify that the WebView only renders JavaScript
contained within the app package.
Object deserialization, if any, is implemented using safe serialization APIs.

The app protects itself against screen overlay attacks. (Android only)

A WebView's cache, storage, and loaded resources (JavaScript, etc.) should be cleared before the
WebView is destroyed.
Verify that the app prevents usage of custom third-party keyboards whenever sensitive data is entered.

Code Quality and Build Settings

The app is signed and provisioned with a valid certificate, of which the private key is properly protected.

The app has been built in release mode, with settings appropriate for a release build (e.g. non-
debuggable).
Debugging symbols have been removed from native binaries.

Debugging code and developer assistance code (e.g. test code, backdoors, hidden settings) have been
removed. The app does not log verbose errors or debugging messages.
All third party components used by the mobile app, such as libraries and frameworks, are identified, and
checked for known vulnerabilities.
The app catches and handles possible exceptions.

Error handling logic in security controls denies access by default.

In unmanaged code, memory is allocated, freed and used securely.

Free security features offered by the toolchain, such as byte-code minification, stack protection, PIE
support and automatic reference counting, are activated.
An Activity is found to be shared with other apps on the device therefore leaving it accessible to any
other application on the device
Definition
Requirement is applicable to mobile App and implemented according to best practices.
Requirement is applicable to mobile App but not fulfilled.
Requirement is not applicable to mobile App.
 Status

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started
Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Pass

Not Started

Not Started

Not Started

Not Started

Not Started

Pass
Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Not Started

Pass

Pass

Not Started

Not Started

Pass

Not Started

Not Started

Not Started

Not Started

Fail
 Testin

Testing Local Storage for Sensitive Data (MSTG-STORAGE-1 and MSTG-STORAGE-2)

Testing Local Storage for Sensitive Data (MSTG-STORAGE-1 and MSTG-STORAGE-2)

Testing Logs for Sensitive Data (MSTG-STORAGE-3)

Determining Whether Sensitive Data is Sent to Third Parties (MSTG-STORAGE-4)

Determining Whether the Keyboard Cache Is Disabled for Text Input Fields (MSTG-STORAGE-5)

Determining Whether Sensitive Stored Data Has Been Exposed via IPC Mechanisms (MSTG-STORAGE-6)

Checking for Sensitive Data Disclosure Through the User Interface (MSTG-STORAGE-7)

Testing Backups for Sensitive Data (MSTG-STORAGE-8)

Finding Sensitive Information in Auto-Generated Screenshots (MSTG-STORAGE-9)

Checking Memory for Sensitive Data (MSTG-STORAGE-10)

Testing the Device-Access-Security Policy (MSTG-STORAGE-11)

Testing User Education (MSTG-STORAGE-12)

Testing Key Management (MSTG-STORAGE-1, MSTG-CRYPTO-1 and MSTG-CRYPTO-5)

Common Configuration Issues (MSTG-CRYPTO-1, MSTG-CRYPTO-2 and MSTG-CRYPTO-3)

Testing the Configuration of Cryptographic Standard Algorithms (MSTG-CRYPTO-2, MSTG-CRYPTO-3 and MSTG-C

Identifying Insecure and/or Deprecated Cryptographic Algorithms (MSTG-CRYPTO-4)

Testing Key Management (MSTG-STORAGE-1, MSTG-CRYPTO-1 and MSTG-CRYPTO-5)

Testing Random Number Generation (MSTG-CRYPTO-6)

Testing Stateful Session Management (MSTG-AUTH-2)

Testing Stateless (Token-Based) Authentication (MSTG-AUTH-3)

Testing User Logout (MSTG-AUTH-4)

Testing Best Practices for Passwords (MSTG-AUTH-5 and MSTG-AUTH-6)

Testing Best Practices for Passwords (MSTG-AUTH-5 and MSTG-AUTH-6)

Testing Session Timeout (MSTG-AUTH-7)

Testing Biometric Authentication (MSTG-AUTH-8)

Testing Two-Factor Authentication and Step-up Authentication (MSTG-AUTH-9 and MSTG-AUTH-10)

Testing Two-Factor Authentication and Step-up Authentication (MSTG-AUTH-9 and MSTG-AUTH-10)

Testing Login Activity and Device Blocking (MSTG-AUTH-11)

Verifying Data Encryption on the Network (MSTG-NETWORK-1 and MSTG-NETWORK-2)

Verifying Data Encryption on the Network (MSTG-NETWORK-1 and MSTG-NETWORK-2)

Testing Endpoint Identify Verification (MSTG-NETWORK-3)

Testing Custom Certificate Stores and Certificate Pinning (MSTG-NETWORK-4)

Making Sure that Critical Operations Use Secure Communication Channels (MSTG-NETWORK-5)

Testing the Security Provider (MSTG-NETWORK-6)

Testing App Permissions (MSTG-PLATFORM-1)

Testing for Injection Flaws (MSTG-PLATFORM-2)

Testing Custom URL Schemes (MSTG-PLATFORM-3)

Testing for Sensitive Functionality Exposure Through IPC (MSTG-PLATFORM-4)

Testing JavaScript Execution in WebViews (MSTG-PLATFORM-5)

Testing WebView Protocol Handlers (MSTG-PLATFORM-6)

Determining Whether Java Objects Are Exposed Through WebViews (MSTG-PLATFORM-7)

Testing Object Persistence (MSTG-PLATFORM-8)

Making Sure That the App is Properly Signed (MSTG-CODE-1)

Testing Whether the App is Debuggable (MSTG-CODE-2)

Testing for Debugging Symbols (MSTG-CODE-3)

Testing for Debugging Code and Verbose Error Logging (MSTG-CODE-4)

Checking for Weaknesses in Third Party Libraries (MSTG-CODE-5)

Testing Exception Handling (MSTG-CODE-6 and MSTG-CODE-7)

Testing Exception Handling (MSTG-CODE-6 and MSTG-CODE-7)

Memory Corruption Bugs (MSTG-CODE-8)

Make Sure That Free Security Features Are Activated (MSTG-CODE-9)

ocedure(s)

Testing Key Management (MSTG-STORAGE-1, MSTG-CRYPTO-1 and MSTG-CRYPTO-5)

Testing Confirm Credentials (MSTG-AUTH-1 and MSTG-STORAGE-11)

Common Configuration Issues (MSTG-CRYPTO-1, MSTG-CRYPTO-2 and MSTG-CRYPTO-3)

Testing the Configuration of Cryptographic Standard Algorithms (MSTG-CRYPTO-2, MSTG-CRYPTO-3 and

MSTG-CRYPTO-4)
Common Configuration Issues (MSTG-CRYPTO-1, MSTG-CRYPTO-2 and MSTG-CRYPTO-3)

Testing the Configuration of Cryptographic Standard Algorithms (MSTG-CRYPTO-2, MSTG-CRYPTO-3 and

MSTG-CRYPTO-4)
Verifying that Appropriate Authentication is in Place (MSTG-ARCH-2 and MSTG-AUTH-1)

Testing OAuth 2.0 Flows (MSTG-AUTH-1 and MSTG-AUTH-3)

Dynamic Testing (MSTG-AUTH-6)

Testing the Network Security Configuration Settings (MSTG-NETWORK-4)

Testing for Fragment Injection (MSTG-PLATFORM-2)
Testing OAuth 2.0 Flows (MSTG-AUTH-1 and MSTG-AUTH-3)
Comment
Resiliency against Reverse Engineering - Android

ID MSTG-ID

8.1 MSTG-RESILIENCE-1

8.2 MSTG-RESILIENCE-2

8.3 MSTG-RESILIENCE-3

8.4 MSTG-RESILIENCE-4

8.5 MSTG-RESILIENCE-5
8.6 MSTG-RESILIENCE-6
8.7 MSTG-RESILIENCE-7

8.8 MSTG-RESILIENCE-8

8.9 MSTG-RESILIENCE-9

8.10 MSTG-RESILIENCE-10

8.11 MSTG-RESILIENCE-11

8.12 MSTG-RESILIENCE-12

8.13 MSTG-RESILIENCE-13

Legend
Symbol
Pass
Fail
N/A
st Reverse Engineering - Android

Resiliency Against Reverse Engineering Requirements

Impede Dynamic Analysis and Tampering
The app detects, and responds to, the presence of a rooted or jailbroken device either by
alerting the user or terminating the app.
The app prevents debugging and/or detects, and responds to, a debugger being attached. All
available debugging protocols must be covered.
The app detects, and responds to, tampering with executable files and critical data within its
own sandbox.
The app detects, and responds to, the presence of widely used reverse engineering tools and
frameworks on the device.
The app detects, and responds to, being run in an emulator.
The app detects, and responds to, tampering the code and data in its own memory space.
The app implements multiple mechanisms in each defense category (8.1 to 8.6). Note that
resiliency scales with the amount, diversity of the originality of the mechanisms used.
The detection mechanisms trigger responses of different types, including delayed and stealthy
responses.
Obfuscation is applied to programmatic defenses, which in turn impede de-obfuscation via
dynamic analysis.
Device Binding
The app implements a 'device binding' functionality using a device fingerprint derived from
multiple properties unique to the device.
Impede Comprehension
All executable files and libraries belonging to the app are either encrypted on the file level
and/or important code and data segments inside the executables are encrypted or packed.
Trivial static analysis does not reveal important code or data.

If the goal of obfuscation is to protect sensitive computations, an obfuscation scheme is used

that is both appropriate for the particular task and robust against manual and automated de-
obfuscation methods, considering currently published research. The effectiveness of the
obfuscation scheme must be verified through manual testing. Note that hardware-based
isolation features are preferred over obfuscation whenever possible.

Impede Eavesdropping
As a defense in depth, next to having solid hardening of the communicating parties, application
level payload encryption can be applied to further impede eavesdropping.

Definition
Requirement is applicable to mobile App and implemented according to best practices.
Requirement is applicable to mobile App but not fulfilled.
Requirement is not applicable to mobile App.
 Status Testing Procedure(s)

Fail Testing Root Detection (MSTG-RESILIENCE-1)

Pass Testing Anti-Debugging Detection (MSTG-RESILIENCE-2)

Not Started Testing File Integrity Checks (MSTG-RESILIENCE-3)

Not Started Testing Reverse Engineering Tools Detection (MSTG-RESILIENCE-4)

Pass Testing Emulator Detection (MSTG-RESILIENCE-5)

Not Started Testing Run Time Integrity Checks (MSTG-RESILIENCE-6)
N/A -

N/A -

Pass Testing Obfuscation (MSTG-RESILIENCE-9)

Not Started Testing Device Binding (MSTG-RESILIENCE-10)

N/A Testing Obfuscation (MSTG-RESILIENCE-9)

N/A -

N/A -
Comment