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

[ell1e]

Resilience and Tampering: From the perspective of an application, tampering is tampering. An app cannot tell whether a modification was made for personal reasons [...] or malicious reasons [...] MASVS-RESILIENCE defines controls that help developers protect their apps from such modifications.

You don't explain why it would be reasonable to prevent such modifications. This isn't done on desktop OSes either, outside of e.g. anti cheat or streaming DRM. Both are widely critized.

The reasonable way to prevent spyware or malware is a scanner for spyware and malware, not anti consumer DRM for every single app. Most anti tampering is widely regarded as anti consumer. If I am mistaken here, please feel free to explain.

Some app devs, e.g. the EU age restriction app, seem to be justifying arguably intrusive and hostile mechanisms with your MASTG, praising themselves for being "more resilient". This suggests your guidelines are doing real harm. Edit: I don't get how "[resilience] is essential" here if the app was designed properly.

[ell1e]

a rooted device or emulator has a larger attack surface. [...] From an app’s perspective, this environment is less trustworthy.

I would like to criticize this as well. A rooted device might actually imply AdGuard being installed which avoids a ton of drive-by Spyware attacks, a technical user who knows what they're doing, and a custom ROM that still receives updates long beyond the manufacturer's end of life. Implying that this is naturally less trustworthy seems to again come from an anti ownership angle. In many people's opinion, this isn't the right road to take and you should reconsider.

Edit: and I don't think this is a "neutral security baseline". But I might be mistaken, of course.

[mpeter50]

The mission of OWASP MAS is to define an industry standard for mobile application security and privacy.

The MASVS industry standard defined by OWASP is heavily tilted towards tech companies. It treats the client device as company property instead of user property. OWASP may not enforce vendor lock-in, as it does not have the powers necessary to do that, but it publishes recommendations that result exactly in vendor lock-in and the restriction of user freedoms.

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.

Both perspectives are moot. While there is truth to both of them, a rooted device is not any less secure than a regular personal computing device, like a windows PC or laptop, which are very fortunately not blocked from accessing important online services. Blocking devices that give extended (relative to what is widespread) control to users does not result in any meaningful added security, it just tells users: we (as a service provider) will not accept users who assume ownership over their own phones, because such a trait is dangerous to our business interests.

Cheating and memory manipulation is only a problem if your backend does not verify that user actions are valid, or if using sensor data is a core part of the game.
While verification of user actions may be hard to solve for multiplayer games because of the server-side performance costs, that is not a reason for most other use cases, like a bank's app or a government app to block access. In these apps there is no continuous stream of user actions like how the player moves, the traffic used is relatively small, actions to be registered on the backend are few and rare. These server-side checks are already essential for security, as you know; without them the services would be breached in short time by bad actors.
For games that primarily rely on location information, maybe they are part of the rare exception where high security measures are warranted. However, for utility apps using such a functionality like family location tracking apps, this should be configurable: the parent or "group administrator" should be able to configure whether a rooted device's location information is to be trusted.

At the same time, we recognize that emulators and custom OS builds are valuable tools for users

Not only custom OS builds, but currently non-mainstream, competing but small operating systems too, the existence of which are necessary to ensure abusive monopolies cannot be created, and that if they happen to get created the users can leave them behind while still being able to participate in society. As of now, the OWASP MASVS standards are supportive of an environment where upholding preexisting monopolies and making them abusive is a breeze.
That purpose does not fall outside of scope: the standard recommends application developers to go against a competition friendly environment. The standard advises developers to create black boxes that refuse operation on compatible software environments, where in most of the cases that is totally unnecessary.

Regarding the illustrative examples, this is not a huge problem for games. They are purely entertainment apps.
But for everyday apps, it very much is. Age verification apps, again, should not depend on device attestation, but on official information verified by strong cryptographic signatures. That way, there is actually no way for the user to tamper with the information - even if the attested device turns out to have a 0-day vulnerability that grants the user to modify the app's data - because verifying the stored information against a known public key reveals if it has been tampered with.
In simpler terms, for an information provider app like this, MASVS-RESILIENCE here is a totally unnecessary measure of blackboxification, as the resilience is to be granted by the cryptographic signature of the provided information. The blackboxification of MASVS_RESILIENCE also results in a situation where the user cannot determine if the app does what it promises to do, because instead of transparency, it obfuscates itself like malware does.
For malware the purpose is to hide the inner workings, to make detection and defense harder, and to make finding out the actions taken (data modified or transferred, backdoors opened) be prohibitively hard. But for a government app, or a commercial app really where users are not competing, what sense does that make?

Our role is to provide a neutral security baseline for mobile apps,

In my opinion, your security baseline is not neutral. Developer teams see the recommendations for integrity checks, and they conclude it is a good idea to have them in any and all apps they make, and that there are no drawbacks, or very little, and its not their problem, and even if it is, it is not their responsibility to prevent monopolies so why not contribute to the creation of them for some sweet pseudo-security against the worst actor: the user.

I think you should at the very least highlight that integrity checks are rarely the solution, they have drawbacks, and recommend that even if teams have started using it as a measure they should rethink it.

[sushi2k]

Thanks to everyone who contributed and shared their feedback in this discussion. We carefully reviewed all points raised and incorporated the ones that were within the scope of the OWASP MASVS:

https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/

If additional changes to the OWASP MASVS or related resources (e.g., OWASP MASTG or MASWE) are desired, we encourage contributors to open PRs with concrete proposals in the respective GitHub repositories.

For topics that fall outside the scope of OWASP MASVS, such as ecosystems or regulatory matters, we recommend engaging with the appropriate entities like governments or other standards bodies.

The OWASP MAS Team - @cpholguera @sushi2k @TheDauntless

[ell1e]

@sushi2k thank you so much for the new modifications.

I would like to propose the addition of one more sentence, after this one:

This results in a platform lock-in, possibly excluding legitimate users from using the application.

My suggestion:

This results in a platform lock-in, possibly excluding legitimate users from using the application. It may also result in weakened user security, in cases where the excluded alternate operating systems or sandboxing mechanisms would have provided a more secure user environment than the default choice.

I would also propose another small addition here, after this one:

Instead, resilience controls provide additional protection against threat-specific attacks

My suggestion:

Instead, resilience controls provide additional protection against threat-specific attacks, while potentially weakening security in other situations.

This should make it even more clear that anti-tampering is by no means an obvious security improvement. Your current text already suggests that it isn't when reading between the lines, but I think it would help to be more on the nose given the seemingly thoughtless uses of anti-tampering by some actors like the EU.