Where should you begin with mobile application security requirements?

Starting a mobile project sounds easy. In most cases, the client knows what the application should do, and designers know how it should look and feel. Problems arise with non-functional requirements โ€“ how the application should operate and behave. One category of these non-functional requirements is security, and it turns out itโ€™s not that difficult to find!

Jakub Czarnojan 2026.04.01   –   5 MIN read

The OWASP Mobile Application Security Verification Standard (OWASP MASVS) provides a well-suited, readily available set of security controls. As a proven industry standard focused on mobile applications, it considers the most critical aspects of their attack surface. This standard has some default profiles which can be used for:  

  1. L1 โ€“ baseline for most applications, essential requirements for low-risk applications;  
  1. L2 โ€“ additional security measures for advanced security need for high-risk application with sensitive data and/or functionality;  
  1. R โ€“ additional security to protect inner-workings of the application and make it resilient against reverse-engineering and tampering;  
  1. P โ€“ additional practices to ensure privacy of user-sensitive data.  

So, preparing a high-risk application with sensitive user data and business logic, we want to protect: L2+R+P profiles would be perfect to ensure a secure experience for end-users. If possible, a custom profile can be created from appropriate security controls with a proper Threat Modeling session. 

This standard is divided into eight control groups related to most critical of the mobile attack surface: 

  • MASVS-STORAGE – protection of sensitive data stored on the device, 
  • MASVS-CRYPTO – verification and correct use of cryptographic functionality, 
  • MASVS-AUTH โ€“ secure authentication and authorization mechanisms, 
  • MASVS-NETWORK โ€“ protection of data in transit, 
  • MASVS-PLATFORM – secure interactions with the underlying mobile operating system, 
  • MASVS-CODE โ€“ secure coding practices, data processing and supply chain security, 
  • MASVS-RESILIENCE โ€“ protection against tampering and reverse engineering, 
  • MASVS-PRIVACY โ€“ protection of user privacy. 

Letโ€™s take closer look into MASVS-AUTH,  control group related to authentication and authorization: 

  1. MASVS-AUTH-1 – The app uses secure authentication and authorization protocols and follows the relevant best practices: 
    Most apps connecting to a remote endpoint require user authentication and also enforce some kind of authorization. While enforcement of these mechanisms must be on the remote endpoint, the apps must also follow all relevant best practices to ensure secure use of the involved protocols. 
  2. MASVS-AUTH-2 – The app performs local authentication securely according to the platform’s best practices: 
    Many apps allow users to authenticate using biometrics or a local PIN. These authentication mechanisms need to be correctly implemented. Additionally, some apps might not have a remote endpoint and rely fully on local app authentication. 
  3. MASVS-AUTH-3 – The app secures sensitive operations with additional authentication: 
    Some additional form of authentication is often desirable for sensitive actions inside the app. This can be done in different ways (biometric, PIN, MFA code generator, email, deep links, etc.), and all of them need to be implemented securely. 

These controls may appear vague, but they are necessary: they must be applicable to mobile applications in general and remain platform-agnostic, regardless of whether the application is designed for iOS or Android. The OWASP Mobile Security Checklist provides platform-specific checks to help determine whether given requirements are met. 

Of course, nowadays mobile applications rarely operate as standalone entities, so the backend, especially its API layer, must be considered from a security standpoint. The OWASP Application Security Verification Standard (OWASP ASVS) is a well-established, mature source of security requirements for web applications. It can address the following backend security concerns: authentication, session management, authorization, input validation and sanitization, cryptography, and logging and monitoring. While these concerns are similar to those in the mobile application, they are located in distinct architectural layers and must be handled to the same extent across the entire ecosystem for the ecosystem to be secure. Additionally, it will provide a set of controls regarding the deployment and configuration of backend infrastructure. Remember – a secure mobile application needs a secure server-side infrastructure. After all, a chain is only as strong as its weakest link.

Letโ€™s take a closer look at one of the chapters from the newest 5.0 version โ€“ V6 Authentication โ€“ since the backend often handles user authentication via the API. It has 8 sections, each containing related requirements. Letโ€™s find security requirements related to passwords โ€“ V6.2 Password Security. The third one is

6.2.3 – โ€œVerify that password change functionality requires the user’s current and new password.”

As we can see, specific, clear, and granular requirements for our backend! 

OWASP also has additional resources that can prove to be helpful! OWASP Testing Guides, especially the mobile one (MASTG) and web-application specific one (WASTG), will provide your testers with the means to verify that security controls are fulfilling their intended roles. OWASP Top Ten projects describes current trends in the most critical security risks for your applications, with separate projects for mobile and APIs: 

The above projects collect and analyse data to help the industry identify the most impactful risks within a given category. For example, the top ten mobile risks for 2024 were: 

Nonetheless, despite all available standards and documentation, external support may still be necessary. This can happen due to missing competencies within the development team or due to regulatory obligations. Certain compliance frameworks (such as DORA) require an independent third-party assessment to confirm that appropriate security standards are being followed. Additionally, as the person responsible for the solution, you may simply want to have its security – especially the critical components – double-checked by experienced security specialists. If you are looking for support with your mobile projectโ€™s security, feel free to reach out to us! 

Connect with the author on LinkedIn!

Requirements engineering, as part of the Secure Software Development Lifecycle, is one of the most crucial phases, laying the foundation for effective solutions.  A good approach in this field can save a lot of time and effort, resulting in a better product at the initial release to production. I believe that with the above set of standards and documents, it would be easier to reach industry-standard levels of security and focus on the most important thing: creating an engaging application for your users that is secure and trustworthy! 

Jakub Czarnojan
Jakub Czarnojan Junior IT Security Consultant