Many of the resilience guidelines seem user hostile and like they undermine data security

[ell1e]

My apologies if I'm just misunderstanding. But I'm getting the impression that many of the resilience guidelines seem user hostile and like they're undermining data security, specifically those listed here https://mas.owasp.org/MASVS/controls/MASVS-RESILIENCE-1/ and https://mas.owasp.org/checklists/MASVS-RESILIENCE/ here at the top.

• Regarding https://mas.owasp.org/MASVS/controls/MASVS-RESILIENCE-1/ this guideline should be rewritten to mean tampering by an advisery. Instead, it seems to imply that any changes by the user, for example having root access for the user, is also harmful tampering.

  This seems in violation of fundamental democratic principles like data ownership and device ownership and user freedom. All anti tampering mechanisms against rooting have fundamental shortcomings that 1. prevent certain custom ROMs, 2. prevent the user from installing free software on a system level that protects them like certain system-wide adblockers, 3. generally prevents a technically advanced user from owning their system as they see fit. Not everybody is clueless when it comes to more advanced usage of their device.

  In summary, preventing root access and locking the device down against the user's intended changes encourages having big data and big Google own your devices instead. This can be, especially for technical users, less secure than allowing the user to take care of their device. It seems to me like that's also anti-competitive.

• Regarding https://mas.owasp.org/checklists/MASVS-RESILIENCE/ this seems to imply root use and emulator use are insecure or unwanted. For root users, see the previous section I wrote above.

  The opposite seems true for emulator use as well. At least in my experience, Emulators are a great defense for the "appification" where apps often grab way more data than a web page from the device, from motion sensors, device id, other running devices via local port scans, and so on, and apps are often made purely to track the user better. Emulators are also a great defense against Google Play Services and other centralization and monopolization mechanisms having access to your personal data. Putting a single app into a single dedicated emulator is one of the best ways to restrict what data it could possibly access about you. It also reduces what other apps it can attack if it breaks out of the app sandbox.

  In conclusion, this emulator ban seems to significantly reduce user privacy and user safety.

These guides sound mostly written to be targeting users that want to not think for themselves and have all their data and security and privacy (and resulting lack thereof) managed by Google and others. While I agree these users exist, this doesn't justify taking away those freedoms away from the user crowd that cares about not doing that. It also seems to go against the Digital Service Act's requirement of interoperability, especially the blocking of emulators.

I would therefore suggest the guides are updated to address these issues. If I simply misunderstood some sections, I'd be happy to learn why.

[Tommimon]

I support this issue

[sofiedotcafe]

I support this issue too!

[mpeter50]

Adding to what ell1e said, emulators are also necessary to run common apps for those people who dont own an android or apple device by their determined choice, so that they can run those apps on their linux phones, or god forbid, their personal computers. In both cases on a device, where the user is the administrator, and not an untouchable tech company.
This is becoming ever more important as service providers stop making functional websites, and transition to only making apps for the 2 biggest mobile platforms.

I also want to highlight what was said about emulators: they also provide a security measure to the user against hostile apps that conduct disgusting, and deep, data collection practices, of which there are thousands, first and foremost including almost all apps of the most popular brands.

Application security should never start at locking away device ownership, and then be done with it. It should always start at the backend servers, and leave your users alone with your arbitrary restrictions as much as possible.
If your company is so unable to secure the backend that you need to rely on restriction of user choice, it is worthy of disappearing forever.

[cpholguera]

Thanks for raising these points. We understand that this touches on sensitive topics around user freedoms, device ownership, and privacy. Our goal here is to clarify the scope and mission of the OWASP MAS project and explain how the controls should be interpreted.

The mission of OWASP MAS is to define an industry standard for mobile application security and privacy. We do this by providing:

• MASVS: security standard for mobile apps.
• MASWE: a catalog of common security and privacy weaknesses in mobile apps.
• MASTG: a testing guide with test cases, processes, and tools.

The focus is on helping developers build secure mobile applications, and enabling testers to evaluate them consistently. OWASP MAS is not a project to enforce vendor lock-in, restrict user freedoms, or regulate how operating systems should be designed.

To clarify some of the main points being raised:

Resilience and Tampering: From the perspective of an application, tampering is tampering. An app cannot tell whether a modification was made for personal reasons (e.g. removing ads) or malicious reasons (e.g. inserting spyware; see backdoored Telegram apps as an example). The techniques can be the same. MASVS-RESILIENCE defines controls that help developers protect their apps from such modifications.

Importantly, resilience controls are never absolute and MASVS-RESILIENCE makes this very clear. Any client-side protection can be bypassed, so these must be treated as defense-in-depth rather than a complete mitigation. Developers should assume that motivated users will eventually find ways around them.

On Rooting and Emulators: There are two perspectives:

• Security: Compared to non-rooted AOSP, a rooted device or emulator has a larger attack surface. SELinux contexts are weaker, and system internals are exposed. From an app’s perspective, this environment is less trustworthy.
• Business / Threat Model: Developers may consider rooted or emulated environments “unwanted” because they make cheating, automation, or memory manipulation easier.

At the same time, we recognize that emulators and custom OS builds are valuable tools for users who want stronger isolation from apps or who want to avoid mainstream services. That purpose, however, falls outside the scope of OWASP MAS. Projects like GrapheneOS or /e/OS focus specifically on building secure environments for users. MAS focuses on app security from the developer and tester perspective.

Illustrative Examples

• Location-based game: The app collects continuous user location data as part of gameplay.

  • MASVS-STORAGE and MASVS-PLATFORM helps ensure that local databases storing this data cannot be accessed by other apps.
  • MASVS-RESILIENCE acknowledges that a rooted user can access their own data, but also notes that a misconfigured rooted device might expose this data to other apps. In addition, rooting or other client-side modifications can enable cheating behaviors such as spoofing location to gain unfair advantages in a location-based game. Developers may choose to add root detection, but this is a business decision. OWASP MAS remains neutral: it documents the available controls without prescribing whether or how they should be applied.
  • MASVS-PRIVACY ensures that the app discloses what data it collects and how it is used, so users can make informed decisions. OWASP MAS requires transparency in declarations, again remaining neutral.

• Government age-verification app: The app verifies whether a user meets legal age requirements.

  • MASVS-STORAGE ensures that sensitive tokens or proofs of ID stored locally are protected from other apps.
  • MASVS-RESILIENCE is essential here, since preventing bypass of the age check is the app’s core purpose. The developer (in this case, the government) should apply the necessary resilience measures to enforce that requirement.

Neutrality and Responsibility

• OWASP MAS does not judge what an app is intended to do. If an app collects data, MASVS-PRIVACY requires it to disclose this transparently. Whether such practices are acceptable is for regulators and users to decide.
• OWASP MAS does not mandate the use of Google services or any vendor-specific technology. Developers are free to choose implementations that fit their threat model and regulatory requirements. If we do, please point it out, as we will gladly fix such a mistake.
• OWASP MAS remains neutral: we provide the framework and best practices. Developers choose which controls to implement, and users decide which apps to use.

We appreciate the feedback and agree that questions of device ownership, interoperability, and user freedom are important. Those questions, however, are broader than the scope of OWASP MAS. Our role is to provide a neutral security baseline for mobile apps, so that developers, testers, and regulators can make informed and consistent decisions.

The OWASP MAS Team - @cpholguera @sushi2k @TheDauntless