OWASP — Mobile application security verification standard
Learn about the mobile application security verification standard and how it can help you secure your applications
The mobile application verification standard is the industry standard for mobile application security. It provides a number of key controls aimed at improving the application security of your mobile application.
Levels
The OWASP MAVS has two/three levels — Level 1, Level 2 and Resilience; the adapted from the MASVS guide itself these levels are summarised as:
MASVS-L1: Standard Security
A mobile app that achieves MASVS-L1 adheres to mobile application security best practices. It fulfils basic requirements in terms of code quality, handling of sensitive data, and interaction with the mobile environment.
MASVS-L2: Defense in depth
MASVS-L2 introduces advanced security controls that go beyond the standard requirements. To fulfill MASVS-L2 security must be an integral part of the app’s architecture and design. Based on the threat model, the right controls should have been selected and implemented successfully.
MASVS-R: Resiliency Against Reverse Engineering and Tampering
The app has state-of-the-art security, and is also resilient against specific, clearly defined client-side attacks, such as tampering, modding, or reverse engineering to extract sensitive code or data.
Checklist
There is a checklist to follow to assure against the standard — split into 8 controls:
Architecture, Design and Threat modelling
Data storage and privacy
Cryptography
Authentication and session management
Network communication
Platform interaction
Code quality and build settings
Resilience requirements
Let’s look at each of these:
Architecture, Design and Threat modelling
Core to this control is the idea that the earlier in the process a security issue is identified and fixed, the better. This first section, then is aimed at ensuring that security is considered before any code has been written — i.e. in the design and architecture phase. Threat modelling is a subject of its own, but primarily the purpose is to break down your applications architecture and highlight each of the risks in it before identifying potential mitigations.
Data storage and privacy
The protection of data is core to secure app development as your users have an expectation that data any data captured or provided is kept safe. On mobile platforms, there are risks to data privacy from improper coding — such as storing data in a location that is accessible to other applications — or via ‘leakage’ to malicious actors & applications, for example using insecure IPC that leads to malicious applications being able to request files that should be secret.
Cryptography
Cryptography is used in application development to secure data in transit and at rest (and for some applications, in memory). Although data encryption is the primary concern, it is important to consider that a failure to using cryptography correctly can lead to weaknesses in integrity and availability as well. In order for cryptography in applications to provide real security, it is important to ensure that the cryptography is implemented correctly, i.e. keys are sufficiently random, strong algorithms are used etc. A sub-category of securing applications is the use of hardcoded or compiled secrets which you erroneously believe is secured with cryptography — this accounts for a surprising number of vulnerabilities, and depending on the nature of the secrets can be a huge security breach — for example if the secrets improperly secured are for cloud accounts.
If you take just one thing from this article, let it be this: don’t put secrets in your application
Authentication and session management
Primarily, authentication and session management vulnerabilities exist on the server-side, but there are mobile specific issues to look out for — in particular to do with removing session tokens on logout, ensuring that multi-user support on a single device is handled correctly, and ensuring that tokens are never exposed to the wrong endpoint by accident
Network communication
Some of the greatest ‘secure by default’ functionality added to mobile platform in recent years has been in enforcing best practice around the use of TLS. That said, there are still mis-steps to be made where TLS is either insufficient, by-passable, or mistakes like open URL redirects are allowed which leads to security issues for application developers.
Platform interaction requirements
Mobile developers are not always aware of the underlying functionality that is available as part of the mobile framework they are using to develop with — and this leads to a number of un-intentional flaws being developed. These include vulnerabilities in IPC (Inter-process communication) — for example, file providers may grant access to all files rather than specific files, deep links might allow open redirects and exposed receivers might allow users to execute code that should not be available to 3rd party apps. Platform interaction vulnerabilities are amongst the most common and most complex to guard against due to the matrix of potential possibilities for attack.
Code quality and build setting
A number of tools and processes exist to make applications more secure — for example the use of PIE reduces the chances of finding an exploitable buffer overflow in your un-managed code — but these features need to be enabled. Similarly, there are things that developers do that make their lives easier — such as debug logging and ‘back doors’ — e.g. turning off TLS for certain URLs — whilst these are fine during the development process, they are potential security holes if the code makes its way into production and therefore caution is needed to ensure that when pushing code to production these developer conveniences do not become hacker conveniences.
Resilience requirements
Primarily implemented as a defence-in-depth measure, resilience requirements addresses four key things:
When attackers attempt to break your application they will attempt to reverse engineer and tamper with the code in order to more easily observe it functioning
Users may un-wittingly be opening themselves up to risk by using your application on un-secure (e.g. rooted) devices
Malware authors have long decompiled legitimate applications, inserted malicious code in it, recompiled and re-released it to unsuspecting users
Competitors may reverse engineer your application in order to understand how you are performing a certain action that they want to steal
For all of these things, we can use resilience to slow down or frustrate the effort of attackers — ideally to the point where the effort to overcome your protection is greater than the benefit of doing so.
Last updated
