OWASP Mobile Top 10 and Mobile Security Framework (MobSF)

Mobile devices sit between personal data, sensitive corporate systems, and untrusted networks, so securing them means protecting storage, communications, identities, and the app runtime itself. Good mobile security combines secure-by-design app development, least-privilege permissions, strong authentication and encryption, timely OS and dependency patching, app hardening (tamper- and debug-resistance), and user education to avoid risky behaviors. That layered approach reduces the chance that malware, man-in-the-middle traffic, stolen credentials, or reverse-engineering will expose data or let attackers pivot into an organization. To make those protections actionable, developers and security teams should consult the OWASP Mobile Top 10, a concise list of the most common mobile-specific risks and use it to prioritize testing, secure coding, and runtime protections. 

M1: Improper Credential Usage 

Definition 
Apps that store, transmit, or reuse credentials insecurely expose user accounts. On mobile this includes saving passwords, tokens, or API keys in plain text, insecure keystores, or backups, allowing attackers who gain device access or backups to impersonate users.

Example 
Scenario #1: Hardcoded Credentials

An attacker discovers hardcoded credentials within the mobile app’s source code. They use these credentials to gain unauthorized access to sensitive functionality within the app or backend systems.

Scenario #2: Insecure Credential Transmission

An attacker intercepts insecurely transmitted credentials between the mobile app and its backend systems. They use these intercepted credentials to impersonate a legitimate user and gain unauthorized access. 

M2: Inadequate Supply Chain Security 

Definition 
Third-party libraries, build tools, CI pipelines, and app-store distribution can introduce malicious code or vulnerabilities. Compromised dependencies or weak signing/build practices let attackers insert backdoors or steal data before the app reaches users.

Example 
Scenario: Malware Injection

An attacker injects malware into a popular mobile app during the development phase. The attacker then signs the app with a valid certificate and distributes it to the app store, bypassing the app store’s security checks. Users download and install the infected app, which steals their login credentials and other sensitive data. The attacker then uses the stolen data to commit fraud or identity theft, causing significant financial harm to the victims and reputational damage to the app provider. 

M3: Insecure Authentication/Authorization 

Definition 
Weak session management, improper use of platform auth (biometrics, OAuth), or flawed access controls let attackers escalate privileges or impersonate users. On mobile this often shows up as token leakage, predictable session IDs, or failing to validate server-side permissions.

Example 
Scenario: Hidden Service Requests

Developers assume that only authenticated users will be able to generate a service request that the mobile app submits to its backend for processing. During the processing of the request, the server code does not verify that the incoming request is associated with a known user. Hence, adversaries submit service requests to the back-end service and anonymously execute functionality that affects legitimate users of the solution.

M4: Insufficient Input/Output Validation 

Definition 
Failure to validate inputs and outputs opens the app to injection, insecure intent handling, and data corruption. Mobile-specific risks include malicious deep links, crafted intents/URIs, or unexpected data from system APIs that lead to crashes or code execution.

Example 
Scenario: Remote Code Execution via Malicious Input

An attacker identifies a mobile application lacking proper input validation and sanitization. By crafting a malicious input containing unexpected characters, they exploit the application’s behavior. Due to insufficient validation, the application mishandles the input, leading to vulnerabilities. The attacker successfully executes arbitrary code, gaining unauthorized access to the device’s resources and sensitive data.

M5: Insecure Communication 

Definition 
Unprotected or poorly validated network traffic exposes sensitive data in transit. On mobile this includes not enforcing TLS, accepting invalid certificates, or transmitting secrets over insecure channels like untrusted Wi-Fi or cleartext telemetry.

Example 
Scenario: Lack of certificate inspection

The mobile app and an endpoint successfully connect and perform a TLS handshake to establish a secure channel. However, the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint. The mobile app is susceptible to man-in-the-middle attacks through a TLS proxy.

M6: Inadequate Privacy Controls 

Definition 
Apps that over-collect, store, or leak personal data without consent violate user privacy. Mobile concerns include unnecessary background sensors access, improper anonymization, or syncing sensitive info to cloud backups without appropriate controls.

Example 
Scenario: Inadequate sanitization of logs and error messages.

Reporting of logs and exceptions is essential for quality assurance of a productive app. Crash reports and other usage data helps developers to fix bugs and learn about how their app is used. However, logs and error messages might contain PII if the developers chose to include this data in log or error messages. Also, third party libraries might include PII in their error messages and logs as well. An example of a frequent issue are database exceptions that reveal part of the query or result. This will most likely be visible to any platform provider used for collecting and evaluating crash reports. It might also become visible to the user if the error is displayed on screen or to attackers who can read device logs. Developers should be especially careful in what they log and ensure that exception messages are sanitized before displaying them to the user or reporting them to a server.

M7: Insufficient Binary Protections 

Definition 
Unprotected binaries are easy to reverse-engineer, modify, or repack. Without obfuscation, integrity checks, or anti-tamper measures, attackers can extract secrets, bypass licensing, or inject malicious code into APK/IPA files.

Example 
Scenario: Hardcoded API keys

Assume an app uses a commercial API where it must pay a small fee for each call. These calls would be easily paid for by the subscription fee the users pay for that app. However, the API key used for access and billing is hardcoded in the app’s unprotected binary code. An attacker who wants access could reverse engineer the app with free tools and get access to the secret string. Since API access is only protected with the API key and no additional user authentication, the attacker can freely work on the API or even sell the API key. In the worst case, the API keys could be misused a lot, causing substantial financial damage to the provider of the app, or at least blocking legitimate users of the app if the API access is rate-limited.

M8: Security Misconfiguration

 Definition 
Incorrect platform, OS, or app settings create avoidable vulnerabilities. Examples on mobile include debuggable builds released to users, overly permissive file permissions, exposed debug endpoints, or misconfigured webviews that allow content injection.

Example 
Scenario #1: Insecure default settings

A mobile app is released with default settings that have weak security configurations enabled. This includes using insecure communication protocols, leaving default usernames and passwords unchanged, and not disabling debugging features in release builds. Attackers exploit these misconfigurations to gain unauthorized access to sensitive data or perform malicious actions.

Scenario #2: Insecure file provider path settings

A mobile app exposes its root path in an exported file content provider, allowing other apps to access its resources.

M9: Insecure Data Storage 

Definition 
Storing sensitive data insecurely on device (plain files, unsecured databases, or logs) allows local attackers or malicious apps to access it. Mobile-specific issues include storing tokens in shared storage, leaving secrets in backups, or failing to use platform-provided encrypted storage.

Example 
Scenario #1: Storing Passwords in Plain Text

The mobile application stores user passwords in plain text format within a local database or file, making it easy for an attacker to retrieve and abuse these credentials if they gain unauthorized access to the device.

Scenario #2: Unsecured Local Storage

The mobile application stores sensitive user data, such as personally identifiable information (PII), locally on the device without utilizing proper access controls or encryption. This allows anyone with physical access to the device to extract and view the data.

M10: Insufficient Cryptography 

Definition 
Using weak, deprecated, or home-rolled crypto leads to broken confidentiality and integrity. On mobile this includes improper key storage, reusing IVs, weak ciphers, or failing to use platform keystores and secure random, making data easy to decrypt or forge.

Example 
Scenario #1: Man-in-the-Middle (MitM) Attacks

An attacker intercepts the communication between the mobile application and the server. Weak cryptography can enable attackers to decrypt the intercepted data, modify it, and re-encrypt it before forwarding it to the intended recipient. This can lead to unauthorized access, data manipulation, or the injection of malicious content.

Scenario #2: Brute-Force Attacks

Attackers systematically try various combinations of keys until they find the correct one to decrypt the data. Weak cryptography can shorten the time required for such attacks, potentially exposing sensitive information 

MobSF (Mobile Security Framework) is an automated, open-source tool for analyzing Android and iOS apps to find security issues. It performs static and dynamic analysis, decompiles binaries, looks for exposed secrets, weak crypto, improper platform usage and other common mistakes, and maps findings to standards like the OWASP Mobile Top 10. Its readable reports and CI-friendly outputs help developers and testers quickly triage vulnerabilities and integrate security checks into their build pipelines. 

Installation

 MobSF can easily be installed with docker using the following commands:

docker pull opensecurity/mobile-security-framework-mobsf:latest 
docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest 
The web application UI will be then available at http://127.0..0.1:8000, or http://localhost:8000  

Static Analysis

MobSF’s static analysis examines mobile app binaries (APK/IPA) without running them: it decompiles code, parses manifests and resources, and scans for hardcoded secrets, insecure permissions/configurations, weak cryptography, dangerous API calls, and other code-level issues. The tool then generates a readable report with findings mapped to OWASP Mobile Top 10, severity/evidence, remediation hints, and useful artifacts (decompiled code, certificate and manifest details) to help developers triage and fix problems.

The Scan will show the Security rating for the app

Along with details about the files, in various field. You can see it at the navigation bar on the left 

Result of the scan can be exported, with detailed report and analysis of the issue 

Dynamic Analysis 

MobSF’s dynamic analysis observes an app while it runs to surface real-world, runtime issues that static scans can miss. It instruments the APK/IPA (or connects to an emulator/real device), hooks APIs (via Frida), captures network traffic, logs, screenshots, filesystem access and memory artifacts, and records behaviors like insecure network calls, credential leakage, unsafe file writes, or permission abuses. The resulting report correlates runtime evidence with OWASP Mobile Top 10 categories so developers can reproduce and remediate problems found during normal app operation.

This feature emulator (Genymotion Android VM/ Android Studio Emulator/ Corellium VM) and obtain the MOBSF_ANALYZER_IDENTIFIER before running MobSF. 

In short: the OWASP Mobile Top 10 gives you a compact, risk-focused checklist of the mobile weaknesses you can expect to encounter, and MobSF is a practical, developer-friendly tool that helps you find and prove those weaknesses through both static and dynamic analysis. Used together they let teams shift security left—automating scans in CI, triaging findings by OWASP category, and validating fixes at runtime—so vulnerabilities are caught early and fixed quickly. Don’t treat scans as a one-off: combine automated MobSF output with targeted manual testing, keep third-party libraries and OS builds patched, train developers on common mobile pitfalls, and ensure legal/test accounts and telemetry are ready for safe testing. Do that, and you move from reactive firefighting to a repeatable, risk-based approach that measurably reduces mobile security exposure.