OWASP Mobile Application Security Testing Guide: 0x03b Testing Profiles

# MAS Testing Profiles

In the realm of mobile app security, adopting a structured and systematic approach is essential to ensure the robustness and resilience of mobile apps against ever-evolving threats. To address this need, the [OWASP Mobile App Security (MAS)](https://mas.owasp.org/) project provides a set of testing profiles that serve as comprehensive frameworks for verifying and enhancing the security of mobile apps.

The **MAS Testing Profiles** outline a series of security controls and tests that can be applied to evaluate mobile app security at different levels of assurance, ranging from fundamental security practices to advanced protective measures. With this, the MAS project provides a flexible framework that allows verification of the appropriate security measures based on the app's unique requirements, risk landscape, and compliance needs.

The MAS Testing Profiles can be used in various ways:

- **App Security Assessment**: Security professionals can leverage the appropriate MAS Testing Profiles based on the app's characteristics to conduct comprehensive assessments to identify vulnerabilities, gaps in security controls, and areas for improvement (e.g. cryptography or secure communication best practices).
- **Secure-by-Design Approach**: Developers can use MAS Testing Profiles as a guideline during the app development lifecycle. By incorporating security controls from the chosen profiles into the design and implementation stages, developers can proactively address security requirements and mitigate potential risks from the early stages of app development.
- **Compliance and Risk Management**: Organizations can rely on the MAS Testing Profiles to align with regulatory and compliance standards specific to the mobile app domain. By mapping the applicable security controls and tests to relevant regulations and industry best practices, organizations can ensure adherence to security requirements and demonstrate their commitment to data protection and privacy.
- **App Vetting Process:** Organizations can use the MAS Testing Profiles as the foundation for app vetting processes before deployment on the organization's devices. The profiles would be carefully tailored and potentially extended with organization-specific security requirements to meet their individual security needs and risk tolerance. See ["NIST.SP.800-163r1 \- Vetting the Security of Mobile Applications"](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-163r1.pdf) for more information.

## The MAS Testing Profiles

To maximize the effectiveness of the OWASP MASVS, applications should undergo a threat model to identify relevant threats and select appropriate security controls. When creating a custom profile isn't feasible, default **L1, L2, R, and P profiles** are available.

These profiles provide baseline security and privacy controls that cover a broad range of common threats, helping developers protect their applications even without a comprehensive threat assessment.

The profiles are divided into **two groups**, reflecting the distinct but complementary goals of **security** and **privacy**:

- **Security profiles (L1, L2, R)**: address technical threats and adversarial behavior.
- **Privacy profile (P)**: focuses on protecting users' personal data and ensuring responsible data handling.

While these defaults offer a solid foundation and can be effective for teams with limited time or resources, they may not cover unique or advanced threats. For the highest level of assurance, a custom profile based on a detailed threat model remains the recommended approach.

### Security

#### MAS-L1 - Essential Security

MAS-L1 provides a baseline for the most fundamental security requirements and best practices that every mobile app should meet to protect against **common threats**.

This profile emphasizes adhering to secure defaults provided by the OS and frameworks and implementing well-recognized security measures considered 'essential'. These include, for example, using TLS or up-to-date strong cryptography. Certain tests are included due to their minimal implementation effort relative to their significant security enhancement.

It assumes that:

- the **security controls of the mobile operating system** can be trusted (e.g. the device is not rooted/jailbroken).
- the **primary user of the device** is not viewed as an adversary.
- **other applications** installed on the device are viewed as an adversary.

MAS-L1 is recommended for

- all mobile apps as a baseline
- apps that only deal with (user) **low-risk sensitive data** and do **not contain sensitive functionality**.

#### MAS-L2 - Advanced Security

MAS-L2 extends MAS-L1, introducing additional security measures and best practices for mobile apps to address **advanced threats** requiring more rigorous threat modeling and testing strategies.

It assumes that:

- the **security controls of the mobile operating system** cannot be trusted (e.g. the device is rooted/jailbroken).
- the **primary user of the device** is not viewed as an adversary.
- **other applications** installed on the device are viewed as an adversary.
- a **third party with or without physical access** is viewed as an adversary.

MAS-L2 is recommended for

- apps that handle **high-risk sensitive data** and **contain sensitive functionality**

#### MAS-R - Resilient Security

MAS-R tries to prevent an attacker from extracting intellectual property, bypassing security controls (e.g., license checks, DRM, authentication) or negatively impacting the ecosystem (e.g. cheating at a game, unlocking paid features for free, …). It incorporates a range of security measures aimed at enhancing resilience against **reverse engineering and tampering (client-side) threats**, such as repackaging or extraction of sensitive data, IP theft (e.g., proprietary algorithms), piracy.

It assumes that:

- the **security controls of the mobile operating system** cannot be trusted (e.g. the device is rooted/jailbroken).
- the **primary user of the device** is viewed as an adversary (e.g. a reverse engineer or cheater).
- **other applications** installed on the device are viewed as an adversary.
- a **third party with or without physical access** is viewed as an adversary.

MAS-R is recommended for

- apps that have a strong need to safeguard their own **business assets and logic**.

Note that the absence of any MAS-R measures does not inherently introduce vulnerabilities. Rather, these measures offer additional, threat-specific protection to applications. However, this is provided that these apps also meet the rest of the OWASP MASVS security controls appropriate to their specific threat models. Crucially, **MAS-R is meant to augment and not replace MAS-L1 and MAS-L2.** It should not be used standalone but as an extra layer of defense, supplementing the base security controls in a defense-in-depth strategy.

Note that these measures cannot assure a 100% effectiveness, as the reverse enginee