OWASP MASTG Best Practices Checklist for Mobile App Security

Mobile applications are at the heart of today’s digital experience, but with their convenience comes a growing landscape of security threats. For developers and security teams, simply building a functional app is no longer enough—protecting user data and business assets must be woven into every stage of the mobile app lifecycle.

That’s where the OWASP Mobile Application Security Testing Guide (MASTG) steps in. Developed by the global security community, MASTG is a hands-on, practical manual designed to help organizations test, validate, and strengthen their mobile applications against real-world vulnerabilities.

Recently, OWASP introduced the MASTG Best Practices—a focused, evolving set of actionable recommendations designed to help DevOps and security teams implement effective security controls from the outset. While the project is still in beta, it’s already setting a new standard for mobile app security by translating complex security requirements into clear, real-world guidance that keeps pace with emerging threats.

In this blog, we will explore some of the key best practices recommended by OWASP MASTG and how they contribute to building secure mobile applications.

Mobile application security best practices (as recommended by OWASP MASTG)

1. Use secure random number generator APIs

Random numbers are often used in cryptographic operations, authentication tokens, and security-sensitive features. 

However, using weak or predictable random number generators can lead to severe vulnerabilities. Developers should always utilize secure random number generator APIs provided by the platform, such as Java’s SecureRandom or iOS’s SecRandomCopyBytes, to ensure randomness and prevent security breaches.

2. Remove logging code before production release

Logging is crucial for debugging during development, but if left enabled in production, it can become a security risk. Sensitive user data, API keys, and authentication tokens may be exposed through logs, making them accessible to attackers. To mitigate this risk, developers should ensure that all logging is disabled or properly sanitized before deploying an application.

Upon production release, tools like ProGuard (included in Android Studio) can help automatically remove logging code. To verify that all logging functions from the android.util.Log class have been eliminated, check the ProGuard configuration file (proguard-rules.pro) and include the following rule:

-assumenosideeffects class com.example.MyLogger {
    public static boolean isLoggable(java.lang.String, int);
    public static int v(...);
    public static int i(...);
    public static int w(...);
    public static int d(...);
    public static int e(...);
}

3. Comply with privacy regulations and best practices

With regulations such as GDPR and CCPA, ensuring user privacy has become a top priority. Applications should implement strict data minimization policies, obtain explicit user consent for data collection, and provide clear transparency regarding how data is processed and stored. Secure storage techniques should be used to protect personal information from unauthorized access.

4. Exclude sensitive data from backups

By default, mobile applications may store data in locations that are included in device backups. If an attacker gains access to a user’s backup, sensitive application data could be exposed. 

Developers should explicitly exclude sensitive information from being included in backups by using configurations such as android:allowBackup=false in Android and NSFileProtectionComplete in iOS.

If your backup includes particularly sensitive data, then it is recommended to either exclude this data or, if you cannot exclude it, require end-to-end encryption. 

To exclude data from backup, configure the backup_rules.xml file located in res/xml. Then, configure the file according to the data persistence and security requirements of the application.

Requiring end-to-end encryption

If you can't exclude sensitive data from your backup, then it is recommended to require end-to-end encryption, which means allowing backups only on Android 9 or higher and only when the lock screen is set. You can achieve this by using the requireFlags="clientSideEncryption" flag, which needs to be renamed to disableIfNoEncryptionCapabilities and set to true starting from Android 12.

Suggested read: OWASP MASVS & MASTG: Redefining Mobile App Security in 2025 [Guide]

5. Use secure encryption modes

Encryption is essential for protecting sensitive data, but using weak encryption modes can render it ineffective. 

Developers should use strong, industry-accepted encryption algorithms, such as AES-GCM or AES-CCM, and avoid insecure modes like ECB, which can leak data patterns. While CBC is more secure than ECB, improper implementation, especially incorrect padding, can lead to vulnerabilities such as padding oracle attacks. Proper IV handling and integrity checks (e.g., HMAC) are necessary when using CBC.

6. Use up-to-date APK signing schemes

For Android applications, using older APK signing schemes can lead to security vulnerabilities, such as APK modification or tampering. 

Developers should always use the latest Android App Signing schemes (such as v2 or v3) to ensure the integrity and authenticity of their applications. Apksigner can help here to verify the signing scheme used to sign the APK.

apksigner verify --verbose app-release.apk

7. Disable the debuggable flag in the AndroidManifest

The android:debuggable flag, when enabled, allows anyone to attach a debugger to the application, potentially exposing sensitive information such as encryption keys, and allows attackers to tamper with the app’s execution. For these reasons, this flag should be set to false in the AndroidManifest.xml file to prevent unauthorized debugging.

<application
    android:debuggable="false" />

8. Disable debugging for WebViews

WebViews allow mobile apps to render web content, but enabling debugging for WebViews in production can be a security risk. Attackers can execute arbitrary JavaScript code, steal user credentials, or bypass security controls. 

Developers should disable debugging features in WebViews using setWebContentsDebuggingEnabled(false) for Android and WKWebView configurations for iOS.

9. Use secure encryption algorithms

Weak or deprecated cryptographic algorithms can be easily cracked by attackers, putting sensitive data at risk. 

Developers should always use modern cryptographic standards, such as AES-256 for encryption and SHA-256 or SHA-3 for hashing. For strong encryption, use AES (Advanced Encryption Standard) with GCM mode for symmetric encryption. 

They should also avoid custom cryptographic implementations and instead rely on well-vetted libraries like OpenSSL, Bouncy Castle, or Apple’s CryptoKit.

How can Appknox help you automate compliance with MASTG?

Staying compliant with OWASP MASTG can be challenging, especially as mobile threats and regulatory requirements evolve. Appknox simplifies this process by integrating automated security testing directly into your development pipeline. Our platform maps every scan to MASTG’s best practices, delivering clear, actionable reports that highlight gaps and provide step-by-step remediation guidance. 

Whether you’re a developer, DevOps manager, security analyst, or CISO, Appknox helps you automate your security compliance and consistently meet the highest security standards, without slowing down your release cycles.

Conclusion

As mobile threats grow more sophisticated, following the best practices recommended by OWASP Mobile Application Security (MAS) is no longer optional—it’s essential for protecting your users, your data, and your brand reputation. 

By following these OWASP MAS best practices and leveraging automation with Appknox, you can confidently keep pace with evolving threats and compliance demands.

🚀 Ready to put OWASP MASTG into action?

Sign up for a free Appknox trial today and start securing your mobile apps with automated testing that checks every box—fast.

Try Appknox for free