OWASP Mobile Top 10: What It Is, Vulnerability List, and How to Apply

What Is OWASP Mobile Top 10?

OWASP Mobile Top 10 is a standardized list of the most critical security risks specific to mobile applications. Unlike the general OWASP Top 10 for web applications, the mobile version accounts for platform specifics: local storage on the device, interaction with sensors, offline modes, and app store peculiarities. The document has been published since 2010 and is revised every 2–4 years: the current version for 2024 includes categories such as M1 — Improper Credential Usage and M8 — Security Misconfiguration. The project is supported by a community of more than 500 volunteers worldwide.

History and Purpose

Originally, OWASP Top 10 only covered web applications, but the growth of mobile development in the 2010s required a separate document. The first version of Mobile Top 10 was released in 2011 and contained only 7 items. By 2024, the list expanded to 10 categories, each including several specific attack scenarios. The main purpose of the document is to give developers and security teams a common language for discussing risks and prioritizing fixes. Regular updates to the list reflect changes in the threat landscape: the emergence of new APIs, the evolution of operating systems (Android, iOS), and new attack techniques described in reports from Positive Technologies and other research centers.

How the OWASP Mobile Top 10 List Is Formed

The methodology for compiling Mobile Top 10 is based on data from real projects: results of mobile application pentests, incident reports, and vulnerability research are analyzed. Each category is evaluated by two parameters: Incidence Rate and Technical Impact. The combination of these metrics forms the final ranking. Unlike subjective lists, OWASP uses open data: any community member can submit a request to include a new category through the project’s GitHub repository. For the current 2024 version, more than 300,000 security tests from 25 countries were processed, making the statistics representative of the global mobile development ecosystem. Additionally, OWASP publishes MASVS (Mobile Application Security Verification Standard) — a set of detailed security requirements that includes more than 80 specific checks distributed across 8 categories. MASVS is used as a basis for application certification and as a checklist for pentests: each requirement has a reference to a Mobile Top 10 category, ensuring traceability between the standard and the risk list.

Overview of Key Vulnerabilities from the Top 10

Let us examine the three most critical categories from OWASP Mobile Top 10 2024, which cover more than 70% of all security incidents in mobile projects. Each category includes specific exploitation scenarios and protection recommendations.

Improper Platform Usage

This category (M1) covers situations where developers use APIs and platform mechanisms improperly. Typical examples: Intent Injection on Android, open Deep Link handlers on iOS, incorrect handling of Keychain and SharedPreferences. An attacker can send a specially crafted Intent and gain access to data from another application or component. According to NowSecure report (2023), 22% of tested Android applications contained Intent Redirection vulnerabilities. Protection includes: strict input validation, verifying the Intent source, and using permissions for exported components.

Insecure Data Storage

Insecure Data Storage (M2) is the most common problem in mobile applications. It occurs when sensitive data (access tokens, passwords, personal data) is stored in plain text or with insufficient protection. Typical sources of vulnerability: SQLite databases without encryption, SharedPreferences without EncryptedSharedPreferences, data logging in debug mode. According to OWASP Foundation (2024), more than 60% of free applications on Google Play store at least one type of sensitive data in unencrypted form. The solution is to use Android EncryptedSharedPreferences, iOS Keychain, and encrypt data before writing to local storage.

Insecure Communication

Category M3 — Insecure Communication — includes vulnerabilities in data transmission channels between the app and the server. Lack of HTTPS, improper SSL certificate validation, use of outdated TLS 1.0/1.1 protocols — all these issues allow an attacker to intercept traffic through Man-in-the-Middle attacks. The situation is especially dangerous when the application works with sensitive data (banking transactions, medical information) through an unprotected channel. In 2023, researchers from NCC Group found that 12% of popular financial applications use incorrect TLS configuration. Recommendation: mandatory use of HTTPS with Certificate Pinning and rejection of HTTP in production builds.

How to Test Applications According to OWASP Mobile Top 10

Security testing of a mobile application using OWASP methodology includes several stages: static code analysis (SAST), dynamic analysis (DAST), and manual testing (pentest). Each stage is aimed at identifying specific vulnerability categories from Mobile Top 10.

Testing Tools

For automated analysis, OWASP recommends using MobSF (Mobile Security Framework) — an open-source tool. MobSF performs static analysis of source code and binary files, checks manifest configuration, analyzes permissions, and identifies vulnerabilities from Mobile Top 10. For dynamic analysis, Burp Suite (proxy for traffic interception) and Frida (runtime analysis tool) are used. The combination of these tools covers more than 80% of the categories in the list. Regular testing in a CI/CD pipeline with MobSF allows identifying vulnerabilities at early development stages and reduces the cost of fixing them by 60–70%. Integration of SAST and DAST tools into the pipeline should be automated via Gradle/Maven plugins or Fastlane steps in iOS builds.

Interpreting the MobSF Report

After running MobSF, the developer receives a report with color indicators: red — critical vulnerability, orange — medium risk, yellow — low risk. Each warning contains a reference to the corresponding OWASP Mobile Top 10 category, a problem description, and a fix recommendation. It is important not only to eliminate red warnings but also to analyze the orange ones: many of them (for example, exported Activities without protection) can combine to give an attacker an attack vector. It is recommended to achieve zero red warnings and no more than 2–3 orange ones before each release. The MobSF report also includes an analysis of application permissions: any excessive permissions (for example, camera access in a calculator) are flagged as a violation of the principle of least privilege and should be removed from the manifest. For iOS applications, MobSF performs a similar analysis of .ipa files, including checking Info.plist for ATS exceptions and analyzing Mach-O binaries for unsafe APIs such as NSAllowsArbitraryLoads.

class InsecureStorage {
    private val prefs = context.getSharedPreferences("my_app", Context.MODE_PRIVATE)

    fun saveToken(token: String) {
        prefs.edit().putString("auth_token", token).apply()
    }

    fun getToken(): String? {
        return prefs.getString("auth_token", null)
    }
}

class SecureStorage(context: Context) {
    private val masterKey = MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build()

    private val securePrefs = EncryptedSharedPreferences.create(
        context,
        "secure_prefs",
        masterKey,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun saveToken(token: String) {
        securePrefs.edit().putString("auth_token", token).apply()
    }
}