OWASP Mobile Top 10 — With Real App Examples

The OWASP Mobile Top 10 list serves as a crucial compass for mobile security. It's not an academic exercise; it's a distilled set of the most critical risks that affect millions of users daily. This i

# OWASP Mobile Top 10 — With Real App Examples

The OWASP Mobile Top 10 list serves as a crucial compass for mobile security. It's not an academic exercise; it's a distilled set of the most critical risks that affect millions of users daily. This isn't about ticking boxes; it's about understanding the *why* and *how* behind these vulnerabilities and, more importantly, how to proactively defend against them with practical, actionable strategies. We’ll dissect each category with anonymized, real-world scenarios, focusing on detection and remediation.

M1: Improper Platform Usage

This category, updated in the 2023 list (and likely to persist in 2026), highlights how developers misuse platform security features, creating exploitable gaps. It's not about finding a new exploit; it's about a fundamental misunderstanding or misapplication of the tools provided by iOS and Android.

Real-World Scenario: Insecure Data Storage via SharedPreferences on Android

Consider a popular e-commerce app where user authentication tokens and session IDs were stored in SharedPreferences without any encryption. An attacker, gaining physical access to a rooted device or exploiting a less sophisticated malware, could easily read these files from /data/data//shared_prefs/.

• Detection:
• Static Analysis: Tools like MobSF (Mobile Security Framework) can flag the use of SharedPreferences for sensitive data. However, this is often a noisy signal, as SharedPreferences is legitimate for non-sensitive data. Context is key.
• Dynamic Analysis: A more effective approach involves observing network traffic and file system activity during app runtime. If sensitive data (like tokens) is written to persistent storage without apparent obfuscation or encryption, it’s a red flag. SUSA’s autonomous exploration, by simulating user journeys, can uncover such data writes through its internal monitoring and analysis. For instance, if a user logs in and then the app writes a JWT to a file, SUSA can correlate this.
• Code Review: Explicitly searching for SharedPreferences.edit().putString() or similar methods that handle sensitive information is crucial.

• Remediation:
• Android: Utilize Android Keystore System for cryptographic operations. Store sensitive data (tokens, API keys) encrypted using keys managed by the Keystore. For instance, using EncryptedSharedPreferences from the AndroidX Security library provides a drop-in replacement for SharedPreferences that encrypts both keys and values.

        // Example using AndroidX Security
        MasterKey masterKey = new MasterKey.Builder(context)
            .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
            .build();

        EncryptedSharedPreferences sharedPreferences =
            new EncryptedSharedPreferences.Builder(context)
            .setPlaintextFileName("secret_prefs.xml")
            .setMasterKey(masterKey)
            .build();

        SharedPreferences.Editor editor = sharedPreferences.edit();
        editor.putString("api_token", "your_secret_token_here");
        editor.apply();

• iOS: Leverage the Keychain Services API for secure storage of sensitive data like passwords, tokens, and certificates. The Keychain is hardware-backed and protected by the device passcode.

        // Example using Keychain Services (simplified)
        let query: [String: Any] = [
            kSecClass as String: kSecClassGenericPassword,
            kSecAttrService as String: "com.yourapp.token",
            kSecValueData as String: tokenData
        ]

        SecItemAdd(query as CFDictionary, nil)

• Cross-Platform (React Native, Flutter): Use libraries that abstract these platform-specific secure storage mechanisms, such as react-native-keychain or flutter_secure_storage.

M2: Insecure Authentication

Flawed authentication mechanisms are a perennial problem. This isn't just about weak passwords; it's about vulnerabilities in session management, token handling, and the overall authentication flow.

Real-World Scenario: Weak Session Token Generation

A social media app generated session tokens using a predictable pattern: user_id_timestamp_random_string. An attacker who knew a user's ID and could guess a plausible timestamp (e.g., when the user was last active) could then brute-force the random string part or, worse, predict valid tokens for other users.

• Detection:
• Traffic Analysis: Intercepting traffic and analyzing session tokens. Look for patterns, fixed lengths, or tokens that change predictably. Tools like Burp Suite or OWASP ZAP are invaluable here.
• Code Review: Examine the code responsible for generating and validating session tokens. Are they using cryptographically secure random number generators? Are they of sufficient length and entropy?
• Fuzzing: Fuzzing authentication endpoints with malformed or predictable tokens can reveal how the backend handles invalid inputs.
• SUSA's Persona-Driven Exploration: By mimicking different user login scenarios and observing token generation and subsequent requests, SUSA can identify if tokens appear weak or easily guessable. If a user logs out and a new token is generated with a very similar structure or predictable component, it’s flagged.

• Remediation:
• Strong Token Generation: Use cryptographically secure pseudo-random number generators (CSPRNGs) to generate tokens. Tokens should be long (e.g., 256 bits), random, and unique. Avoid including predictable information like timestamps or user IDs directly in the token.
• Secure Session Management:
• Token Expiration: Implement short-lived access tokens and use refresh tokens for longer sessions. Refresh tokens should also have a reasonable expiry and be stored securely.
• Token Revocation: Provide a mechanism to revoke tokens on logout or if a compromise is suspected.
• HTTPS Everywhere: Ensure all communication, especially authentication endpoints, uses HTTPS to prevent token interception.
• OAuth 2.0 and OpenID Connect: For complex authentication flows, leverage industry standards like OAuth 2.0 and OpenID Connect, implemented correctly.

M3: Insecure Network Communication

This vulnerability arises when sensitive data is transmitted over the network without adequate protection, making it susceptible to eavesdropping and Man-in-the-Middle (MitM) attacks.

Real-World Scenario: Plaintext API Calls for User Data

A mobile banking app, during its initial development, made API calls to retrieve user account balances and transaction history over plain HTTP. Even if the app enforced HTTPS for login, subsequent requests for sensitive data might have fallen back to HTTP if the server configuration was lax or if there were internal API endpoints not properly secured.

• Detection:
• Network Traffic Interception: Use tools like Wireshark, mitmproxy, or Burp Suite to capture and analyze network traffic. Look for any API calls transmitting sensitive information over HTTP or with unencrypted payloads.
• Certificate Pinning Analysis: Check if the app implements certificate pinning. Lack of pinning makes it easier for attackers to use forged certificates in MitM attacks.
• Static Code Analysis: Scan the codebase for URLs that do not start with https:// or for libraries that might handle network requests insecurely.
• SUSA's Network Monitoring: SUSA can monitor all outbound network requests during its exploration. If it detects sensitive data (e.g., user PII, financial details) being sent over plain HTTP, it will immediately flag this as a critical vulnerability. It can also detect if SSL/TLS connections are established with untrusted or self-signed certificates.

• Remediation:
• HTTPS for All Communication: Mandate the use of HTTPS for all network requests, including internal API calls. Configure web servers to redirect HTTP to HTTPS.
• Certificate Pinning: Implement certificate pinning to ensure the app only communicates with servers presenting a specific, trusted certificate. This prevents MitM attacks using fraudulent certificates.
• Android (Network Security Configuration):

            <!-- res/xml/network_security_config.xml -->
            <network-security-config>
                <domain-config>
                    <domain includeSubdomains="true">api.example.com</domain>
                    <pin-set expiration="2024-12-31">
                        <pin digest="SHA-256">...</pin> <!-- Base64 encoded SHA-256 hash of the server's public key -->
                    </pin-set>
                </domain-config>
            </network-security-config>

Reference this in AndroidManifest.xml:

            <application ... android:networkSecurityConfig="@xml/network_security_config">

• iOS: Use URLSession with custom delegate methods to validate server certificates. Libraries like Alamofire offer utilities for certificate pinning.
• Data Encryption: Even over HTTPS, consider encrypting sensitive data payloads before transmission, especially if dealing with highly classified information.

M4: Insecure Coding Practices

This broad category encompasses a multitude of coding errors that can lead to vulnerabilities. It's about writing code that is not only functional but also secure by design.

Real-World Scenario: SQL Injection via User Input

A legacy content management app allowed users to search for articles using a free-text field. The backend constructed SQL queries by directly concatenating user input. A malicious user could enter input like ' OR '1'='1 to bypass authentication or extract all data from the database.

• Detection:
• Static Application Security Testing (SAST): Tools like SonarQube, Checkmarx, or Veracode can scan code for common vulnerability patterns, including SQL injection, cross-site scripting (XSS), buffer overflows, and insecure deserialization.
• Dynamic Application Security Testing (DAST): Tools that interact with the running application to probe for vulnerabilities.
• Code Review: Experienced developers meticulously review code for insecure patterns.
• SUSA's Autonomous Exploration: SUSA’s personas can interact with input fields in ways that trigger these vulnerabilities. For example, by entering special characters, malformed data, or known exploit payloads into text fields, SUSA can observe if the app crashes, reveals error messages, or exhibits unexpected behavior indicative of injection attacks. Its ability to analyze UI elements and their corresponding backend calls is key here.

• Remediation:
• Parameterized Queries (Prepared Statements): Always use parameterized queries or prepared statements for database interactions. This separates SQL code from user-supplied data, preventing malicious input from being interpreted as commands.

        // Example using JDBC Prepared Statement
        String sql = "SELECT * FROM articles WHERE title LIKE ?";
        PreparedStatement statement = connection.prepareStatement(sql);
        statement.setString(1, "%" + userInput + "%"); // userInput is safely handled
        ResultSet resultSet = statement.executeQuery();

• Input Validation and Sanitization: Validate all user input against expected formats and lengths. Sanitize input by encoding or removing potentially dangerous characters before processing.
• Least Privilege: Ensure that the application's database user has only the necessary permissions.
• Secure Deserialization: If deserializing untrusted data, use safe deserialization methods or avoid deserialization altogether.
• Dependency Management: Keep libraries and frameworks updated to patch known vulnerabilities. Tools like OWASP Dependency-Check can help.

M5: Sensitive Data Exposure

This category covers the improper handling of sensitive information, leading to its leakage through logs, insecure storage, or unencrypted transmission.

Real-World Scenario: Debug Logs Containing PII

A retail app, during its development phase, logged user session details, including names, email addresses, and partial credit card numbers, directly to the device's log files (Log.d() or NSLog). While intended for debugging, these logs could be accessed by other applications with sufficient permissions or by an attacker with device access.

• Detection:
• Log File Analysis: Tools that can access and parse device logs. On Android, adb logcat can be used. On iOS, logs can be accessed through Xcode or other debugging tools.
• Static Analysis: Scan code for logging statements that include sensitive keywords like "password," "credit card," "email," "SSN," etc.
• Dynamic Analysis: Monitor the application's behavior and check for any sensitive data appearing in unexpected places.
• SUSA's Data Leakage Detection: SUSA's autonomous exploration can simulate user actions that might trigger logging of sensitive data. It can then analyze the captured logs (or monitor system calls related to logging) for any PII or other confidential information. If SUSA detects a user logging in and then sees Log.d("User logged in: " + userName + ", email: " + userEmail) in the captured logs, it flags this.

• Remediation:
• Avoid Logging Sensitive Data: Never log sensitive user data such as passwords, credit card numbers, social security numbers, or personally identifiable information (PII).
• Mask or Obfuscate Data: If logging is necessary for debugging, mask or obfuscate sensitive fields. For example, log only the last four digits of a credit card number.
• Release Builds: Ensure debug logging is disabled or significantly restricted in release builds. Use build flags or configuration settings to control logging levels.
• Secure Storage for Logs: If logs must be stored, ensure they are stored securely and have restricted access.
• Runtime Permissions: Be mindful of runtime permissions that grant access to sensitive data and ensure they are requested only when necessary and with user consent.

M6: Insufficient Cryptography

This refers to the use of weak or outdated cryptographic algorithms, incorrect implementation of cryptographic functions, or poor key management.

Real-World Scenario: Using MD5 for Password Hashing

An older enterprise app stored user passwords hashed using MD5. MD5 is known to be cryptographically broken and highly susceptible to rainbow table attacks and brute-force collisions. An attacker could easily retrieve user passwords by hashing common passwords and comparing them to the stored hashes.

• Detection:
• Static Code Analysis: Scan for the use of deprecated or weak cryptographic functions (e.g., MD5, SHA1 for hashing passwords, DES for encryption). Libraries like Bouncy Castle might be used, and static analysis can check for specific algorithms.
• Binary Analysis: Decompile or analyze the application binary to identify cryptographic primitives used.
• Dependency Scanning: Check for outdated cryptographic libraries that may have known vulnerabilities.
• SUSA's Code Analysis Capabilities: While SUSA primarily focuses on runtime behavior, its underlying analysis engine can identify the use of known insecure crypto functions within the application's code dependencies or direct implementation.

• Remediation:
• Strong Hashing Algorithms: For password hashing, use modern, strong, and slow algorithms like bcrypt, scrypt, or Argon2. These are computationally expensive, making brute-force attacks much harder.

        # Example using bcrypt in Python
        import bcrypt

        password = b"mysecretpassword"
        # Generate a salt and hash the password
        hashed_password = bcrypt.hashpw(password, bcrypt.gensalt())
        print(hashed_password)

        # To verify
        if bcrypt.checkpw(password, hashed_password):
            print("Password matches")

• Secure Encryption: Use modern, strong encryption algorithms like AES-256 with appropriate modes (e.g., GCM) and secure padding.
• Key Management: Implement robust key management practices. Keys should be generated securely, stored safely (e.g., using hardware security modules or secure enclaves), and rotated periodically.
• Algorithm Agility: Design systems to be algorithm-agnostic, allowing for easier upgrades to newer, stronger algorithms as they become available.

M7: Improper Access Control

This vulnerability occurs when an application fails to enforce restrictions on what authenticated users are allowed to do or see. It's about ensuring users can only access resources and perform actions they are authorized for.

Real-World Scenario: Horizontal Privilege Escalation in a Multi-Tenant App

A SaaS platform allowed users to manage their company's data. However, a bug in the access control logic allowed User A from Company X to view and modify User B's data within Company X by simply manipulating the user ID in an API request URL (e.g., changing /api/users/123/data to /api/users/456/data where 456 was another user in the same company).

• Detection:
• Authorization Testing: Manually or automatically test if users can access data or perform actions outside their permitted scope. This involves trying to access resources of other users, different tenants, or elevated privileges.
• API Fuzzing: Fuzz API endpoints with different user roles and credentials to uncover authorization bypasses.
• Code Review: Scrutinize authorization checks at every entry point (API endpoints, UI actions) to ensure they are robust and correctly implemented.
• SUSA's Persona-Based Testing: SUSA can simulate multiple user personas with different roles and permissions. By having one persona attempt to access or modify data belonging to another persona (even within the same "tenant" or group), SUSA can detect horizontal or vertical privilege escalation. For example, if a "standard user" persona can trigger an "admin action" or access another "standard user's" private data, it's flagged.

• Remediation:
• Principle of Least Privilege: Grant users only the minimum permissions necessary to perform their tasks.
• Server-Side Enforcement: All authorization checks must be performed on the server-side. Client-side checks are easily bypassed.
• Role-Based Access Control (RBAC): Implement a clear RBAC model. Define roles, assign permissions to roles, and then assign roles to users.
• Tenant Isolation: In multi-tenant applications, strictly enforce tenant boundaries. Ensure that user requests are always validated against the authenticated user's tenant ID.
• Contextual Authorization: Authorization checks should consider the full context of the request, not just the authenticated user ID.

M8: Security Misconfiguration

This category covers insecure default settings, incomplete configurations, open cloud storage, verbose error messages, and other configuration-related security flaws.

Real-World Scenario: Debug Mode Enabled in Production

A mobile game shipped with its debug mode enabled in the production build. This exposed sensitive internal game state, allowed direct manipulation of game variables, and provided verbose error messages that could reveal system architecture details.

• Detection:
• Configuration Audits: Regularly audit application configurations, server settings, cloud storage permissions, and API gateways.
• Vulnerability Scanners: Use scanners to identify common misconfigurations (e.g., open S3 buckets, default credentials).
• Penetration Testing: Conduct penetration tests specifically looking for misconfigurations.
• SUSA's Configuration Checks: While SUSA primarily operates on the deployed application, its ability to infer certain configurations through runtime analysis can be useful. For example, if an app consistently provides overly detailed error messages that reveal database schema or internal file paths, it can flag this as a potential misconfiguration. It can also detect if the app is running with elevated permissions it doesn't seem to require.

• Remediation:
• Secure Defaults: Always configure systems and applications with security in mind from the start. Disable unnecessary features, services, and ports.
• Production Hardening: Implement strict security hardening guidelines for production environments. Remove debug symbols, disable verbose error messages, and restrict administrative access.
• Regular Patching and Updates: Keep all software, including operating systems, web servers, databases, and application frameworks, up-to-date with the latest security patches.
• Cloud Security Best Practices: For cloud deployments, adhere to cloud provider security best practices, including proper IAM policies, network security groups, and data encryption.
• Automated Configuration Management: Use tools like Ansible, Chef, or Puppet to automate configuration and ensure consistency and adherence to security policies.

M9: Code Tampering

This relates to vulnerabilities that allow attackers to modify the application's code or data, leading to unauthorized behavior, privilege escalation, or data theft.

Real-World Scenario: Unsigned or Weakly Signed Code Libraries

A mobile utility app included third-party libraries that were either unsigned or signed with weak certificates. An attacker could potentially replace these libraries with malicious versions, which the app would then execute, granting the attacker control over the app's functions or access to its data.

• Detection:
• Integrity Checks: Implement runtime integrity checks to verify that the application code and its critical components have not been tampered with. This can involve checksumming, code signing verification, and anti-tampering techniques.
• Reverse Engineering Analysis: Analyze the application binary for signs of modification, such as unpacked code segments or altered function calls.
• App Store Verification: Ensure applications are downloaded from trusted sources and verify their digital signatures.
• SUSA's Runtime Integrity Monitoring: SUSA, by its nature, operates on the installed application. It can perform checks to ensure the application's code and critical assets haven't been altered since its initial installation or known good state. It can detect if hooks or modifications have been injected into the application's runtime environment.

• Remediation:
• Code Signing: Ensure all application code and libraries are properly signed with strong, trusted digital certificates.
• Runtime Application Self-Protection (RASP): Integrate RASP solutions that can detect and respond to tampering attempts in real-time.
• Root/Jailbreak Detection: While not foolproof, detecting if the device is rooted or jailbroken can be a deterrent, as these environments often facilitate code tampering.
• Obfuscation: Use code obfuscation techniques to make reverse engineering and tampering more difficult.
• Secure Bootstrapping: Ensure the initial loading of the application and its critical components is secure.

M10: Reverse Engineering

This category addresses vulnerabilities that arise from an application's susceptibility to reverse engineering, allowing attackers to understand its logic, extract sensitive information, or find vulnerabilities.

Real-World Scenario: Unobfuscated Sensitive API Keys

A mobile app hardcoded API keys for accessing backend services directly in its source code, without any obfuscation. When decompiled, these keys were immediately visible, allowing attackers to impersonate the app and gain unauthorized access to backend resources.

• Detection:
• Decompilation and Static Analysis: Tools like Jadx (Android), Ghidra, or IDA Pro can decompile application binaries. Analyze the decompiled code for hardcoded secrets, sensitive logic, or easily identifiable vulnerabilities.
• String Analysis: Look for hardcoded strings that might reveal sensitive information, API endpoints, or encryption keys.
• Dynamic Analysis: Observe the app's behavior during runtime to understand its logic and identify sensitive operations.
• SUSA's Code Insights: While SUSA doesn't perform deep reverse engineering in the traditional sense, its analysis of code dependencies and runtime behavior can identify patterns indicative of reverse engineering potential. For example, if SUSA can easily map UI elements to specific functions without obfuscation, it suggests a lack of reverse engineering protection.

• Remediation:
• Code Obfuscation: Employ robust code obfuscation tools (e.g., ProGuard/R8 for Android, Swift code obfuscation techniques for iOS) to make the code harder to read and understand. This includes renaming classes, methods, and variables, and controlling the flow of execution.
• Avoid Hardcoding Secrets: Never hardcode API keys, encryption keys, or other sensitive credentials directly in the application code. Use secure configuration management systems or fetch them dynamically from a secure backend.
• Runtime Integrity Checks: As mentioned in M9, implement checks that can detect if the app is running in a compromised environment or has been modified.
• Minimize Sensitive Logic: Move sensitive business logic to the server-side whenever possible. The client should primarily handle UI and user interaction.
• Root/Jailbreak Detection: Implement measures to detect and respond to rooted or jailbroken devices, as these environments are conducive to reverse engineering.

The Continuous Cycle of Security Assurance

The OWASP Mobile Top 10 is not a static checklist but a dynamic reflection of the evolving threat landscape. Each category represents a significant risk that, if left unaddressed, can lead to data breaches, financial loss, and reputational damage.

The key takeaway is that security is not an afterthought; it must be integrated into every stage of the mobile application development lifecycle. This involves:

1. Secure Development Practices: Educating developers, using secure coding guidelines, and performing regular code reviews.
2. Automated Security Testing: Leveraging tools for SAST, DAST, and IAST throughout the CI/CD pipeline.
3. Manual Security Testing: Conducting penetration tests and manual code reviews for deeper vulnerability discovery.
4. Runtime Protection: Employing RASP and other runtime security measures to protect the application in production.
5. Continuous Monitoring and Learning: Regularly updating security practices based on new threats and vulnerability intelligence.

Platforms like SUSA, by offering autonomous exploration that mimics real user behavior and automatically generates regression scripts, can significantly accelerate the detection of many of these OWASP Top 10 vulnerabilities. Its ability to find crashes, ANRs, dead buttons, and critically, security issues and UX friction, all while learning and adapting to the application’s evolving state, provides a crucial layer of continuous assurance. By proactively addressing these OWASP categories with the specific strategies outlined, development teams can build more robust, trustworthy, and secure mobile applications.