The Mobile Application Security Verification Standard (MASVS) is an OWASP project that is the result of the amazing work done by Carlos Holguera (@grepharder) and Sven Schleier (@bsd_daemon) and generously supported by NowSecure.

MASVS serves as a standard for mobile application security that developers and mobile software engineers can utilize to secure mobile apps.

Security testers can also use the standard to verify the consistency and completeness of test results.

Through these goals, MASVS can provide a baseline and a level of confidence in the security of a mobile application.

OWAP Security Levels

MASVS defines three levels of compliance's, L1, L2, and Resilience.

OWASP L1: Standard Security

L1 is the mobile security testing baseline for All mobile applications. It lists security best practices that can be followed with a reasonable impact on development cost and user experience. All applications must apply the requirements in MASVS-L1 for any app.

OWASP L2: Defense-in-Depth

MASVS-L2 introduces advanced security controls that go beyond the standard requirements. To fulfill MASVS-L2, a threat model must exist, and security must be an integral part of the app's architecture and design. Based on the threat model, the right MASVS-L2 controls can be selected and implemented successfully. This level is appropriate for apps that handle highly sensitive data, such as mobile banking apps.

OWASP Resilience: Resiliency Against Reverse Engineering and Tampering

The last level is Resilience, it ensures protection against client-side threats, used for Mobile apps where IP protection is a business goal. The resiliency controls listed in MASVS-R can be used to increase the effort needed to obtain the original source code and to impede tampering or cracking.

OWASP Security Requirements Groups:

MASVS has broken down its requirements in the form of MSTG-IDs. MSTG-IDs are grouped into the following groups: Architecture Design and Threat Modeling Requirements: This requirement addresses security when planning the architecture of the mobile app. The goal is to identify all the functional components and security roles. In addition, since most mobile applications act as clients to remote services, this requirement ensures that testing the mobile app in isolation is not sufficient.

• Data Storage and Privacy Requirements: The protection of sensitive data, such as user credentials and private information, is a critical focus in mobile security. Firstly, sensitive data can be unintentionally exposed to other apps running on the same device if operating system mechanisms like IPC are used improperly. Data may also unintentionally leak to cloud storage, backups, or the keyboard cache. Mobile devices can be lost or stolen more easily compared to other devices, so an adversary gaining physical access is a more likely scenario. This requirement ensures the presence of additional protections to make retrieving sensitive data more difficult.

• Cryptography Requirements: Cryptography is an essential ingredient when it comes to protecting data stored on a mobile device. It is also a category where things can go horribly wrong, especially when standard conventions are not followed. The purpose of the controls in this chapter is to ensure that the verified application uses cryptography according to industry best practices, including: Use of proven cryptographic libraries Proper choice and configuration of cryptographic primitives

• Authentication and Session Management Requirements: In most cases, users logging into a remote service is an integral part of the overall mobile app architecture. Even though most of the logic happens at the endpoint, MASVS defines some basic requirements regarding how user accounts and sessions are to be managed.

• Network Communication Requirements: The purpose of this section is to ensure the confidentiality and integrity of information exchanged between the mobile app and remote service endpoints. At the very least, a mobile app must set up a secure, encrypted channel for network communication using the TLS protocol with appropriate settings. Level 2 lists additional defense-in-depth measures such as SSL pinning.

• Platform Interaction Requirements: The controls in this group ensure that the app uses platform APIs and standard components in a secure manner, covering communication between apps using IPCs.

• Code Quality and Build Setting Requirements: The goal of this control is to ensure that basic security coding practices are followed and that "free" security features offered by the compiler are activated.

• Impede Dynamic Analysis and Tampering: The controls in this section should be applied as needed, based on an assessment of the risks caused by unauthorized tampering of the app and/or reverse engineering of the code. Consult the OWASP document "Technical Risks of Reverse Engineering and Unauthorized Code Modification Reverse Engineering and Code Modification Prevention" for a list of business risks as well as associated technical threats.

• 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 at the file level and/or important code and data segments inside the executables are encrypted or packed. The trivial static analysis does not reveal important code or data.

Ostorlab MASVS Scan Coverage

Ostorlab new standards feature will automatically generate a report showcasing issues with meeting the MASVS standard levels.

The reports can easily be accessed by navigating to the standards tab in the scan report. You can navigate between them easily meaning that you can change from one level to another based on the technical objective, so you can prioritize which level to focus on. Each level will list the corresponding categories with a description including the issues found, clear indications of the findings with their risk ratings, tags, title, description, and a reference to the vulnerability itself.

Each OWASP level is followed by the number of issues found colored by red, otherwise, you will see a label with no issues found.

You can already generate your report using the Ostorlab free community scanner and list any findings that affect your different compliance levels.