OWASP Mobile Top 10 Vulnerabilities [2024 Updated]

With over 6.8 billion smartphone users worldwide and mobile apps accounting for 70% of digital interactions, securing mobile applications is more critical than ever. In 2023 alone, mobile app vulnerabilities contributed to approximately 40% of data breaches involving personal data.

The OWASP Mobile Top 10 list for 2024 serves as a benchmark for identifying and addressing the most pressing mobile security threats. This guide provides an in-depth look at each risk, offering insights for developers, security teams, and decision-makers.

Top 10 OWASP Mobile Risks 2024

1. M1: Improper Credential Usage

Threat Agents

Application-Specific

Threat agents exploiting hardcoded credentials and improper credential usage in mobile applications often include automated attacks using publicly available or custom-built tools. These agents can locate and exploit hardcoded credentials or take advantage of weaknesses caused by improper credential handling.

Attack Vectors

Exploitability: Easy

Adversaries can exploit vulnerabilities in hardcoded credentials and improper credential usage. Once identified, these vulnerabilities enable attackers to use hardcoded credentials to gain unauthorized access to sensitive mobile app functionalities. They can also misuse improperly validated or stored credentials, bypassing legitimate access controls.

Security Weakness

Prevalence: Common
Detectability: Easy

Poor credential management, such as hardcoded credentials or improper handling, can lead to severe security weaknesses. Comprehensive security testing should aim to identify these issues. Security testers should examine the mobile app’s source code and configuration files to detect any hardcoded credentials. 

Technical Impacts

Impact: Severe

Inadequate credential management can result in significant technical consequences. Unauthorized users may access sensitive information or functionalities within the mobile app or its backend systems. This could lead to data breaches, loss of user privacy, fraudulent activities, and unauthorized access to administrative functions.

Business Impacts

Impact: Severe

Poor credential management can cause substantial business repercussions, including:

• Reputation damage
• Information theft
• Fraud
• Unauthorized data access

Am I Vulnerable to Improper Credential Usage?

Insecure credential management often occurs when mobile apps use hardcoded credentials or mishandle them. Signs your mobile app may be vulnerable include:

• Hardcoded Credentials: Presence of hardcoded credentials within the app’s source code or configuration files.
• Insecure Credential Transmission: Transmission of credentials without encryption or through insecure channels.
• Insecure Credential Storage: Storing user credentials on the device insecurely.
• Weak User Authentication: Reliance on weak authentication protocols or those easily bypassed.

How Do I Prevent Improper Credential Usage?

Preventing insecure credential management involves avoiding hardcoded credentials and properly handling user credentials.

Avoid Using Hardcoded Credentials

Hardcoded credentials are easily discovered by attackers and provide unauthorized access points. Avoid embedding credentials in your app’s code or configuration files. 

Properly Handle User Credentials

Ensure secure storage, transmission, and authentication of user credentials:

• Encrypt credentials during transmission.
• Avoid storing credentials on the device; use secure, revocable access tokens instead.
• Implement strong user authentication protocols.
• Regularly update and rotate API keys or tokens.

Example Attack Scenarios

These scenarios illustrate improper credential usage in mobile apps:

1. Hardcoded Credentials: An attacker finds hardcoded credentials in the app’s source code, using them to access sensitive app functionalities or backend systems.
2. Insecure Credential Transmission: An attacker intercepts credentials transmitted insecurely between the app and backend systems, impersonating a legitimate user.
3. Insecure Credential Storage: An attacker with physical access to a user’s device extracts stored credentials from the app and gains unauthorized access to the user’s account.

2. M2: Inadequate Supply Chain Security

Threat Agents

Application Specific

Attackers can exploit vulnerabilities in the mobile app supply chain to manipulate application functionality. For instance, malicious code can be injected into the app’s codebase or altered during the build process, introducing backdoors, spyware, or other harmful components.

This can enable attackers to steal data, spy on users, or take control of mobile devices. They may also exploit vulnerabilities in third-party software libraries, SDKs, vendors, or hardcoded credentials, gaining unauthorized access to the mobile app or backend servers.

Consequences include data theft, service disruption, or a complete system takeover.

Attack Vectors

Exploitability: AVERAGE

Exploiting an inadequate supply chain can occur through various methods. For example, an insider or external attacker might inject malicious code during the development phase and compromise app signing keys or certificates to disguise malicious code as trusted.

Additionally, vulnerabilities in third-party libraries or components can be exploited to compromise the app.

Security Weakness

Prevalence: COMMON
Detectability: DIFFICULT

This vulnerability often results from poor secure coding practices, insufficient code reviews, and inadequate testing, which allow vulnerabilities into the app. Other factors include weak app signing processes, insecure third-party components, and insufficient security controls for data handling and storage.

Technical Impacts

Impact: SEVERE

Successful exploitation can lead to severe consequences:

• Data Breach: Attackers may steal sensitive data, including login credentials, personal information, and financial details, leading to identity theft or financial fraud.
• Malware Infection: Malicious code introduced into the app can infect user devices, steal data, or perform harmful activities. Such malware is often hard to detect and remove, causing significant damage.
• Unauthorized Access: Attackers may gain unauthorized access to servers or user devices, modify or delete data, and disrupt services.
• System Compromise: Complete system control could be lost, resulting in application shutdowns, data loss, and reputational damage for developers.

Business Impacts

Impact: SEVERE

The business impact depends on factors like organizational size, industry, and security posture. Potential consequences include:

• Financial Losses: Costs related to breach investigations, user notifications, and legal settlements can be substantial. Loss of customer trust may also lead to revenue decline.
• Reputational Damage: A security breach can harm an organization’s brand and customer trust, impacting long-term revenue and customer acquisition.
• Legal and Regulatory Consequences: Non-compliance with regulations can lead to fines, lawsuits, or government investigations, causing significant financial and reputational damage.
• Supply Chain Disruption: Attacks may interrupt service delivery, leading to financial losses and reputational harm.

Am I Vulnerable to Inadequate Supply Chain Vulnerabilities?

You might be vulnerable, especially if your mobile applications rely on third-party developers or components. Key risk factors include:

• Insecure Third-Party Components: Vulnerabilities in libraries or frameworks can be exploited if not properly vetted or updated.
• Malicious Insider Threats: Rogue developers or suppliers could intentionally introduce vulnerabilities if security controls are insufficient.
• Inadequate Testing: Poor testing and validation practices may leave the application exposed to attacks.
• Lack of Security Awareness: Developers unaware of supply chain security risks might fail to implement necessary controls.

Prevention Strategies

• Implement secure coding practices, thorough code reviews, and comprehensive testing throughout the development lifecycle.
• Ensure secure app signing and distribution processes to prevent malicious code from being trusted.
• Use only verified and trusted third-party libraries or components.
• Establish security controls for app updates, patches, and releases.
• Continuously monitor and detect supply chain security incidents through security testing and scanning.

Example Attack Scenario

Scenario #1: Malware Injection

An attacker injects malware into a popular mobile app during development. They sign the app with a valid certificate and distribute it through an app store, bypassing security checks. Users download the infected app, which steals login credentials and sensitive data. The attacker then uses the stolen information for fraud or identity theft, causing financial harm to users and damaging the app provider’s reputation.

3. M3: Insecure Authentication/Authorization

Threat Agents

Application-Specific

Threat agents exploiting authentication and authorization vulnerabilities often leverage automated attacks using readily available or custom-built tools.

Attack Vectors

Exploitability: EASY

Once adversaries understand vulnerabilities in an authentication or authorization scheme, they can exploit these weaknesses in two primary ways. They may either fake or bypass authentication by directly submitting service requests to the mobile app’s backend server, avoiding direct interaction with the mobile app, or log in as legitimate users after passing the authentication control, then force-browse to a vulnerable endpoint to execute administrative functionality. These methods are typically facilitated by mobile malware or attacker-controlled botnets. 

Security Weakness

Prevalence: COMMON
Detectability: AVERAGE

To test for weak authentication and authorization schemes in mobile apps, several strategies can be employed:

• Authorization Testing: Conduct binary attacks on the app to attempt privileged functionality access with low-privilege user tokens, especially when offline.
• Session Token Testing: Use low-privilege session tokens in POST/GET requests to sensitive backend functionalities.

Poor or missing authorization schemes might allow adversaries to access privileged functionalities using a lower-privilege authenticated user. The risk is heightened when authorization is managed on the mobile device rather than a remote server, often for offline usability.

• Authentication Testing: Perform binary attacks to bypass offline authentication and execute restricted functionalities. Test backend server functionality without session tokens to identify anonymous access.

Weak authentication schemes can enable anonymous access to app functionalities or backend servers. These weaknesses are common due to mobile device limitations, often leading to the use of short passwords or PINs.

Technical Impacts

Impact: SEVERE

Poor authorization and authentication can lead to significant technical impacts, including unauthorized access to sensitive information and system destruction. Poor authentication weakens user activity logging, making it difficult to detect attacks or devise mitigation strategies.

Failures in authentication often expose underlying authorization weaknesses, allowing adversaries to execute privileged functions anonymously. This indicates a failure in verifying both the user’s identity and permissions. 

Business Impacts

Impact: SEVERE

Consequences of weak authentication and authorization typically include:

• Reputation damage
• Information theft
• Fraud
• Unauthorized data access

Am I Vulnerable to Insecure Authentication/Authorization?

Understanding the difference between authentication (user identification) and authorization (permission verification) is essential. Indicators of insecure authorization include:

• IDOR Vulnerabilities: Lack of proper authorization checks.
• Hidden Endpoints: Assuming backend functionality is accessible only by authorized users.
• Role/Permission Transmission: Sending user roles/permissions as part of requests.

Indicators of insecure authentication include:

• Anonymous Backend API Execution: Accessing backend services without tokens.
• Local Storage of Passwords: Storing sensitive data on devices.
• Weak Password Policies: Simplified password requirements.
• Biometric Features: Relying solely on FaceID or TouchID.

How to Prevent Insecure Authentication and Authorization

Avoid Weak Patterns:

• Ensure mobile authentication requirements match web equivalents.
• Avoid local authentication to prevent client-side bypasses.
• Perform server-side authentication and load data only after successful login.
• Encrypt locally stored data securely.
• Never store passwords in “Remember Me” functions.
• Use device-specific tokens, revocable within the app.
• Avoid spoofable authentication methods, like device IDs or geolocation.

Reinforce Authentication:

• Assume client-side controls can be bypassed; enforce server-side checks.
• Implement integrity checks for offline authentication.
• Secure sensitive authentication materials with biometrics.

Prevent Insecure Authorization:

• Verify user roles and permissions server-side.
• Implement integrity checks for offline authorization.

Example Attack Scenarios

1. Hidden Service Requests: Backend code processes requests without verifying user identities, allowing adversaries to execute functionality anonymously.
2. Interface Reliance: Backend processes requests without confirming the user’s entitlement to access certain functions, enabling unauthorized administrative access.
3. Usability Requirements: Short passwords (e.g., 4-digit PINs) make systems vulnerable to brute-force attacks.
4. Insecure Direct Object Reference (IDOR): Failing to validate actor IDs allows attackers to access others’ data by modifying URLs.
5. LDAP Role Transmission: Backend trusts user-supplied LDAP group information, allowing attackers to spoof their roles and access sensitive functions.

4. M4: Insufficient Input/Output Validation

Threat Agents

Application-Specific

Insufficient validation and sanitization of data from external sources, such as user inputs or network data, in a mobile application can introduce severe security vulnerabilities. Mobile apps that fail to properly validate and sanitize such data are at risk of exploitation through attacks specific to mobile environments, including SQL injection, command injection, and cross-site scripting (XSS) attacks.

These vulnerabilities can have severe consequences, including unauthorized access to sensitive data, manipulation of app functionality, and potential compromise of the entire mobile system.

Inadequate output validation can lead to data corruption or presentation vulnerabilities, allowing malicious actors to inject harmful code or manipulate sensitive information displayed to users.

Attack Vectors

Exploitability: DIFFICULT

Insufficient input/output validation exposes an application to critical attack vectors, such as SQL injection, XSS, command injection, and path traversal. These vulnerabilities can result in unauthorized access, data manipulation, code execution, and the compromise of the entire backend system. 

Security Weakness

Prevalence: COMMON
Detectability: EASY

Insufficient input/output validation occurs when an application fails to properly check and sanitize user input or validate output data. This vulnerability can be exploited in several ways:

• Insufficient Input Validation: When user input is not thoroughly checked, attackers can manipulate it by entering unexpected or malicious data. This can bypass security measures, leading to code execution vulnerabilities or unauthorized system access.
• Insufficient Output Validation: If output data is not properly validated and sanitized, attackers can inject malicious scripts that execute in users’ browsers, potentially leading to XSS attacks, data theft, session hijacking, or content manipulation.
• Lack of Contextual Validation: Failing to consider the specific context or expected data formats can result in vulnerabilities such as SQL injection or format string attacks. These occur when unvalidated user input is directly incorporated into database queries or improperly handled in format string functions.
• Failure to Validate Data Integrity: Without validating data integrity, an application becomes vulnerable to data corruption or incorrect processing. Attackers can tamper with system variables or introduce malformed data that disrupts functionality.

These vulnerabilities often arise from application logic errors, incomplete validation checks, lack of security awareness, or insufficient testing and code reviews. 

Technical Impacts

Impact: SEVERE

Insufficient input/output validation can have several technical impacts:

• Code Execution: Exploiting this vulnerability can allow attackers to execute unauthorized code within the application, bypassing security measures.
• Data Breaches: Attackers can manipulate input, potentially gaining unauthorized access to sensitive data.
• System Compromise: Attackers may gain unauthorized access to the underlying system, potentially taking control of it.
• Application Disruption: Malicious input can cause crashes, data corruption, or instability, affecting reliability and functionality.
• Reputation Damage: Exploitation can harm an organization’s reputation due to data breaches and loss of customer trust.
• Legal and Compliance Issues: Inadequate validation can result in legal liabilities, regulatory penalties, and non-compliance with data protection regulations.

Business Impacts

Impact: SEVERE

From an application perspective, impacts include:

• Code Execution: Exploitations may lead to system compromise and unauthorized access.
• Data Breaches: Attackers can manipulate inputs, leading to unauthorized access to sensitive information.
• System Disruptions: Exploitation can cause crashes or data corruption, leading to operational inefficiencies.
• Data Integrity Issues: Insufficient validation may result in corrupted data or inaccurate outputs, compromising system reliability. 

From a business standpoint, impacts include:

• Reputation Damage: Data breaches and system disruptions can lead to customer distrust and damage the organization’s brand.
• Legal and Compliance Consequences: Non-compliance with regulations can result in penalties and financial losses.
• Financial Impact: Incident response, remediation costs, and potential revenue loss due to data breaches or disruptions.

Am I Vulnerable to Insufficient Input/Output Validation?

Applications can be vulnerable due to:

• Lack of Input Validation: Failure to validate user input exposes the application to injection attacks.
• Inadequate Output Sanitization: Insufficient sanitization can result in XSS vulnerabilities.
• Neglecting Context-Specific Validation: Overlooking specific validation requirements can create vulnerabilities like path traversal.
• Insufficient Data Integrity Checks: Failure to validate data integrity can lead to corruption or unauthorized modifications.
• Poor Secure Coding Practices: Neglecting practices like parameterized queries contributes to vulnerabilities.

How to Prevent Insufficient Input/Output Validation

• Input Validation:
  Validate and sanitize user input using strict validation techniques.
  Implement input length restrictions and reject unexpected data.
• Output Sanitization:
  Properly sanitize output data to prevent XSS attacks.
  Use output encoding techniques when displaying or transmitting data.
• Context-Specific Validation:
  Perform validation based on data context to prevent path traversal or injection attacks.
• Data Integrity Checks:
  Implement checks to detect and prevent data corruption.
• Secure Coding Practices:
  Use parameterized queries and prepared statements to prevent SQL injection.
• Regular Security Testing:
  Conduct regular security assessments, including penetration testing and code reviews.

Example Attack Scenarios

Scenario #1: Remote Code Execution via Malicious Input
An attacker exploits a mobile application with poor input validation by submitting malicious input containing unexpected characters. The application mishandles this input, allowing the attacker to execute arbitrary code and gain unauthorized access to device resources.

Scenario #2: Injection Attacks via Insufficient Output Validation
An attacker exploits inadequate output validation by injecting code through user-generated content. The application fails to sanitize this input, allowing XSS or SQL injection attacks that compromise sensitive data.

Scenario #3: Remote Code Execution via Malformed Output
An attacker submits specially crafted data to a mobile application with insufficient output validation. The application processes this data without proper checks, enabling remote code execution and unauthorized control over device resources.

5. M5: Insecure Communication

Threat Agents

Application Specific

Modern mobile applications often exchange data with remote servers. During data transmission, the information typically travels through the mobile device’s carrier network and the internet. If the data is transmitted in plaintext or using deprecated encryption protocols, a threat agent monitoring the network can intercept and modify it. Threat agents may have various motives, such as stealing sensitive information, conducting espionage, or committing identity theft. Common threat agents include:

• Adversaries on the same local network (e.g., compromised or monitored Wi-Fi)
• Rogue carriers or network devices (e.g., routers, cell towers, proxies)
• Malware on the mobile device

Attack Vectors

Exploitability: EASY

Although modern applications rely on cryptographic protocols such as SSL/TLS, they can still suffer from flawed implementations. These flaws may include:

• Using deprecated protocols or poor configuration settings
• Accepting invalid SSL certificates (e.g., self-signed, revoked, expired, incorrect host)
• Inconsistent application (e.g., using SSL/TLS only for certain workflows like authentication)

Security Weakness

Prevalence: COMMON
Detectability: AVERAGE

While most mobile applications aim to secure network traffic, implementation inconsistencies can create vulnerabilities. These flaws can expose data and session IDs to interception. Just because an app uses transport security protocols doesn’t mean they are correctly implemented. Basic flaws can be identified by observing network traffic, but more subtle issues require deeper analysis of the application’s design and configuration.

Technical Impacts

Impact: SEVERE

Insecure communication can expose user data, leading to account takeovers, user impersonation, and leaks of personally identifiable information (PII). For instance, attackers might intercept user credentials, sessions, or two-factor authentication tokens, enabling further attacks.

Business Impacts

Impact: MODERATE

Intercepting sensitive data during transmission can result in privacy violations. Consequences of confidentiality breaches include:

• Identity theft
• Fraud
• Reputational damage

Am I Vulnerable to ‘Insecure Communication’?

This risk involves insecure data transmission between two points. It applies to various communication methods, including mobile-to-server, mobile-to-mobile, and mobile-to-other-device channels. Relevant technologies include TCP/IP, Wi-Fi, Bluetooth, NFC, infrared, GSM, 3G, and SMS.

Sensitive data, such as encryption keys, passwords, session tokens, and personal information, is vulnerable when transmitted. If the data remains local on the device, it falls under Insecure Data. If session details are communicated securely but the session identifier is weak, it becomes an Insecure Authentication issue.

Common risks include:

• Data Integrity Issues: Changes during transit undetected by the system (e.g., man-in-the-middle attacks)
• Data Confidentiality Risks: Exposure through real-time eavesdropping or recorded offline attacks
• TLS Configuration Errors: Failing to validate SSL/TLS certificates or using weak ciphers

Preventing ‘Insecure Communication’

General Best Practices

• Assume the network is insecure and prone to eavesdropping.
• Use SSL/TLS for all data transmission to backend services.
• Implement strong, industry-standard cipher suites with appropriate key lengths.
• Use certificates signed by trusted Certificate Authorities (CA).
• Never allow invalid certificates (self-signed, expired, untrusted root, revoked, or mismatched hosts).
• Consider certificate pinning and require SSL chain verification.
• Verify the endpoint server’s identity before establishing secure connections.
• Alert users if the app detects invalid certificates.
• Avoid sending sensitive data over alternate channels (e.g., SMS or MMS).
• Add an extra encryption layer for sensitive data before it enters the SSL channel.
• During development, use self-signed certificates or a local CA instead of bypassing SSL verification.
• Assess application traffic to detect plaintext transmissions during security reviews.

iOS-Specific Best Practices

• Ensure certificates are valid and fail securely.
• Use the Secure Transport API with CFNetwork for strong encryption.
• After development, remove code that allows self-signed certificates.
• Consider certificate pinning for additional security.

Android-Specific Best Practices

• Remove any code that accepts all certificates, such as AllowAllHostnameVerifier.
• Ensure the checkServerTrusted method in SSLSocketFactory is properly implemented.
• Avoid overriding onReceivedSslError to accept invalid certificates.

Example Attack Scenarios

1. Lack of Certificate Inspection:
   The app connects to an endpoint but doesn’t inspect the server’s certificate, accepting any certificate. This makes the app vulnerable to man-in-the-middle attacks via TLS proxies.
2. Weak Handshake Negotiation:
   The app negotiates a weak cipher suite during a TLS handshake, making encryption easy for attackers to break and compromising data confidentiality.
3. Privacy Information Leakage:
   Personally identifiable information (PII) is transmitted over insecure channels instead of SSL/TLS, risking privacy breaches.
4. Credential Information Leakage:
   User credentials are sent over insecure channels, allowing attackers to intercept them.
5. Two-Factor Authentication Bypass:
   Session identifiers are transmitted without SSL/TLS, enabling attackers to bypass two-factor authentication.

6. M6: Inadequate Privacy Controls

Threat Agents

Application-Specific

Privacy controls focus on safeguarding Personally Identifiable Information (PII), such as names, addresses, credit card details, email and IP addresses, and sensitive information regarding health, religion, sexuality, and political opinions.

This data is valuable to attackers for several reasons. For instance, an attacker could:

• Impersonate the victim to commit fraud.
• Misuse the victim’s payment information.
• Blackmail the victim with sensitive data.
• Harm the victim by destroying or manipulating critical data.

PII can be compromised in several ways: leaked (confidentiality violation), manipulated (integrity violation), or destroyed/blocked (availability violation).

Attack Vectors

Exploitability: Average

Typical PII sources are well-protected, such as app sandboxes, network communications with servers, logs, and backups. Some sources, like URL query parameters and clipboard content, offer less protection but are still difficult to access.

To obtain PII, an attacker typically needs to breach another security layer. This may involve eavesdropping on network communication, accessing the file system, clipboard, or logs with a Trojan, or extracting data from device backups. Since PII can be stored, processed, and transmitted in various ways on mobile devices, attackers have numerous avenues for extraction or manipulation.

Security Weakness

Prevalence: Common
Detectability: Easy

Most apps handle some form of PII, often collecting more data than necessary, making them attractive targets.

Risks of privacy violations increase due to poor handling of PII by developers. Data should always be processed with the assumption that an attacker could access communication and storage media.

An app is vulnerable if it collects personal data that an attacker could manipulate or misuse through inadequately secured storage or transmission mediums.

Technical Impacts

Impact: Low

Privacy violations typically have minimal technical impact on the overall system. However, if PII includes authentication data, it could affect global security properties, such as traceability.

Manipulating user data might render the system unusable for that user. Ill-formed data could also disrupt the backend if proper sanitization and exception handling are absent.

Business Impacts

Impact: Severe

The severity of a privacy violation depends on the number of affected users, the criticality of the data, and applicable data protection regulations. Consequences usually include:

• Legal Violations: Regulations like GDPR (Europe), CCPA (California), PDPA (Singapore), PIPEDA (Canada), LGPD (Brazil), Data Protection Act 2018 (UK), POPIA (South Africa), and PDPL (China) impose sanctions for failing to protect user data.
• Financial Damage: Affected individuals may sue the app provider. Success depends on applicable laws and the provider’s ability to demonstrate adequate protections.
• Reputational Damage: Large-scale privacy breaches attract negative media attention, potentially reducing app usage and impacting other products from the same provider.
• Loss/Theft of PII: Stolen data can be misused, such as in social engineering attacks against the provider.

Assessing Vulnerability to Inadequate Privacy Controls

An app is vulnerable if it processes any PII, which is almost always the case. Examples include IP addresses, usage logs, and crash report metadata. Sensitive PII such as account details, payment data, and locations are common targets.

Common vulnerabilities include:

• Insecure data storage and communication.
• Insecure authentication and authorization for data access.
• Insider attacks on app sandboxes.

Preventing Inadequate Privacy Controls

The safest way to prevent privacy violations is to minimize the amount and variety of PII processed. This requires a thorough awareness of all PII assets in an app. Key considerations include:

• Is all PII necessary (e.g., name, address, age)?
• Can less sensitive data replace PII (e.g., coarse-grained location instead of fine-grained)?
• Can PII be reduced (e.g., location updates hourly instead of every minute)?
• Can PII be anonymized or blurred (e.g., hashing, bucketing, or adding noise)?
• Can PII be deleted after a certain period?
• Can users consent to optional PII collection, understanding the additional risk?

The remaining PII should only be stored or transferred when absolutely necessary, with proper authentication and authorization. Defense-in-depth strategies, like encrypting health data using keys sealed in the device’s TPM, provide additional security.

Threat modeling can help identify likely privacy violation scenarios, allowing focused efforts to secure PII. Static and dynamic security tools can reveal common issues, such as logging sensitive data or leaking it to the clipboard or URL parameters.

Example Attack Scenarios

Scenario 1: Inadequate Log and Error Message Sanitization
Logs and error messages often help developers fix bugs, but they might inadvertently contain PII. This data could be visible to platform providers or attackers with log access. Developers should sanitize logs and error messages before reporting or displaying them.

Scenario 2: Using PII in URL Query Parameters
URL query parameters are visible in server logs, website analytics, and browser history. Sensitive information should be sent in headers or the request body, not in query parameters.

Scenario 3: Inclusion of Personal Data in Backups
App developers should explicitly configure which data to include in backups. An attacker could access sensitive data from backups. Additionally, setting hasFragileUserData to true in Android can prevent data from being accessed if a malicious app is installed later.

Explicit settings help control the information flow between backups and app installations.

7. M7: Insufficient Binary Protection

Threat Agents

Application-Specific Threats

Attackers targeting app binaries have various motivations.

The binary might contain valuable secrets, such as commercial API keys or hardcoded cryptographic data, which attackers could exploit. Additionally, the code itself may be valuable due to critical business logic or embedded pre-trained AI models. Some attackers might not target the app directly but instead use it to identify weaknesses in the backend, setting the stage for future attacks. 

Besides information gathering, attackers might manipulate app binaries to unlock paid features for free or bypass security checks. In severe cases, popular apps could be altered to include malicious code and redistributed via third-party stores or under new names, targeting unsuspecting users. A common scenario involves modifying payment identifiers, repackaging the app, and distributing it through unauthorized channels. When users download this altered version, the attacker receives payments instead of the original provider. 

Attack Vectors

Exploitability: EASY

App binaries can usually be downloaded from app stores or copied from mobile devices, making binary attacks relatively easy to execute.

Two main types of attacks on app binaries are:

1. Reverse Engineering: Decompiling the app binary to extract valuable information, such as secret keys, algorithms, or vulnerabilities.
2. Code Tampering: Modifying the app binary to remove license checks, circumvent paywalls, or gain other unauthorized benefits. Alternatively, the app could be altered to include malicious code.

Security Weakness

Prevalence: COMMON
Detectability: EASY

All apps are vulnerable to binary attacks, and many will eventually be targeted. Apps containing sensitive data or hardcoded algorithms are especially at risk. Effective countermeasures aim to increase the difficulty and cost for attackers, ideally deterring them due to diminishing returns. For example, in copy protection, prolonging the cracking process until the app reaches its revenue goals can be sufficient.

Fully compiled apps (like iOS) are generally less susceptible to reverse engineering and tampering compared to higher-level bytecode in Android apps. However, cross-platform apps (e.g., built with PWA or Flutter) may not share this advantage.

Popular apps are more likely to be manipulated and redistributed. Detecting and removing such copies can be managed through specialized services or built-in detection and reporting mechanisms.

While no mechanism can completely prevent binary attacks, developers must decide how much effort to invest in protective measures based on potential risks and impacts.

Technical Impacts
Impact: MODERATE

Binary attacks may involve reverse engineering, leaking information from the binary, or code tampering, altering how the app functions.

• Information Leaks: If sensitive data (e.g., API keys) leaks, replacing them system-wide is challenging, particularly when hardcoded. Such leaks can also expose backend vulnerabilities.
• Code Manipulation: This poses a greater risk to system integrity. Attackers can alter app behavior for personal gain or to disrupt backend systems, especially if these lack adequate protections against malicious requests.

Business Impacts

Impact: MODERATE

Leaked API keys or tampered apps can lead to significant costs if exploited at scale. For instance, removing license checks or cloning app functionality can provide competitors with an unfair advantage. Individual misuse might go unnoticed, but large-scale exploitation can be financially damaging.

Intellectual property theft such as proprietary algorithms or AI models poses a severe threat, especially when competitors access these assets.

Reputational damage is also a concern. If popular apps are redistributed with malicious code, the original provider may face negative publicity despite limited control over third-party distribution. Minimizing this risk is essential.

Am I Vulnerable to ‘Insufficient Binary Protection’?

All apps are inherently vulnerable to binary attacks. Risks increase if sensitive data or critical logic is hardcoded or if the app is popular. Protective measures (like obfuscation) can increase attack difficulty but never eliminate the risk.

Assessing vulnerability depends on potential business impacts. Higher risks warrant stronger protections. Developers can simulate attacks using tools such as MobSF, otool, apktool, and Ghidra to evaluate their app’s resilience.

How Do I Prevent ‘Insufficient Binary Protection’?

Assess each app for critical content within its binary or factors that might increase its attack appeal. Threat modeling can identify high-risk areas and their potential financial impacts, guiding countermeasure implementation.

Key strategies include:

• Reverse Engineering Prevention: Use obfuscation tools to make the binary harder to understand. Native compilation and nested virtual machines further complicate decompilation. Obfuscation quality can be tested using attacker-like tools.
• Breaking Security Mechanisms: Obfuscation complicates control flow analysis, but backend verification should enforce local security checks. Integrity checks can detect tampering, though attackers may also bypass these.
• Redistribution Prevention: Implement integrity checks to detect binary modifications and report unauthorized copies. Specialized companies can assist in detecting and removing these versions from app stores.

Example Attack Scenarios

1. Hardcoded API Keys: An app using commercial APIs with hardcoded keys could be reverse-engineered, allowing attackers to misuse or sell the keys, causing financial damage or service disruptions.
2. Disabling Payment Checks: In mobile games with free and paid levels, attackers might bypass license checks to unlock content for free, potentially redistributing the altered app under a different name.
3. Extracting AI Models: A medical app with a proprietary AI model could be reverse-engineered, with the model and usage insights sold to competitors, jeopardizing intellectual property and competitive advantage.

8. M8: Security Misconfiguration

Threat Agents

Application Specific

Security misconfiguration in mobile apps refers to improper configuration of security settings, permissions, and controls, leading to vulnerabilities and unauthorized access. Threat agents who exploit these misconfigurations are attackers aiming to access sensitive data or perform malicious actions. These agents can include attackers with physical access to the device or malicious apps exploiting misconfigurations to execute unauthorized actions within the vulnerable application context. 

Attack Vectors

Exploitability: Difficult

Security misconfigurations in mobile apps can be exploited through various vectors, including:

• Insecure default settings: Apps may have default configurations with weak security settings or unnecessary permissions, making them vulnerable to attacks.
• Improper access controls: Misconfigured access controls can allow unauthorized users to access sensitive data or perform privileged actions.
• Weak encryption or hashing: Improperly implemented or weak encryption and hashing algorithms can be exploited to access sensitive information.
• Lack of secure communication: Failing to use secure protocols like SSL/TLS can expose data to eavesdropping and man-in-the-middle attacks.
• Unprotected storage: Storing sensitive data (e.g., passwords or API keys) in plain text or weakly encrypted formats can lead to unauthorized access.
• Insecure file permissions: Application files with world-readable or world-writable permissions can be compromised.
• Misconfigured session management: Poor session management can result in session hijacking, allowing attackers to impersonate legitimate users.

Security Weakness

Prevalence: Common
Detectability: Easy

Security misconfigurations are common in mobile apps due to time constraints, lack of awareness, or human error during development. Detecting them is relatively easy through manual code review, security testing, or automated scanning tools.

Examples include:

• Failure to disable debugging features in release builds, exposing sensitive information.
• Allowing insecure communication protocols (e.g., HTTP) instead of enforcing HTTPS.
• Leaving default usernames and passwords unchanged.
• Inadequate access controls allowing unauthorized users to perform privileged actions.

Technical Impacts

Impact: Severe

Security misconfigurations can significantly impact mobile apps by enabling:

• Unauthorized access to sensitive data: Attackers may access user credentials, personal data, or confidential business information.
• Account hijacking or impersonation: Weak authentication mechanisms can lead to account takeover.
• Data breaches: Poor configurations can expose sensitive data.
• Compromise of backend systems: Misconfigurations can provide attackers with a foothold to compromise backend infrastructure. 

Business Impacts

Impact: Severe

Security misconfigurations can lead to:

• Financial loss: Breaches may result in legal penalties, regulatory fines, and reputational damage.
• Data loss or theft: Exposure of sensitive data can lead to legal and financial consequences.
• Downtime and disruption: Exploited misconfigurations can cause app downtime and service interruptions.
• Reputation damage: Publicly disclosed incidents can erode customer trust and impact business.

Am I Vulnerable to Security Misconfigurations?

Mobile apps are vulnerable if they lack proper security configurations. Indicators include:

• Default settings not reviewed or changed.
• Unencrypted or weakly encrypted communication channels.
• Weak or absent access controls.
• Failure to apply security updates or patches.
• Storing sensitive data in plain text or weak formats.
• Exposed internal file provider paths or activities, increasing the attack surface.

To determine vulnerabilities, conduct thorough security assessments, including code reviews, security testing, and configuration analysis.

How Do I Prevent Security Misconfigurations?

Preventing security misconfigurations requires adherence to secure coding and configuration practices:

• Secure default configurations: Ensure default settings do not expose sensitive information.
• Avoid hardcoded default credentials.
• Restrict file permissions: Avoid overly permissive settings like world-readable or writable.
• Apply the least privilege principle: Request only necessary permissions.
• Secure network configurations: Disallow cleartext traffic and use certificate pinning.
• Disable debugging features in production apps.
• Disable backup mode on Android to prevent sensitive data from being included in device backups.
• Limit the attack surface: Only export necessary activities, content providers, and services.

Example Attack Scenarios

1. Insecure Default Settings:
   A mobile app with weak default configurations (e.g., using HTTP, unchanged default credentials) is exploited to access sensitive data.
2. Insecure File Provider Paths:
   An app exposes its root path through an exported file content provider, allowing other apps to access its resources.
3. Overly Permissive Storage Permissions:
   Application preferences stored with world-readable permissions are accessible by other apps.
4. Exported Activities:
   An internal activity is exported, providing attackers with additional attack surfaces.
5. Unnecessary Permissions:
   An app requests excessive permissions, like a flashlight app accessing contacts or location data, increasing the risk of data leaks or misuse.

9. M9: Insecure Data Storage

Threat Agents

Application Specific

Insecure data storage in mobile applications can attract various threat agents aiming to exploit vulnerabilities and gain unauthorized access to sensitive information. These agents include:

• Skilled adversaries: Target mobile apps to extract valuable data.
• Malicious insiders: Misuse their privileges within the organization or app development team.
• State-sponsored actors: Conduct cyber espionage.
• Cybercriminals: Seek financial gain through data theft or ransom.
• Script kiddies: Utilize pre-built tools for basic attacks.
• Data brokers: Exploit insecure storage to sell personal information.
• Competitors and industrial spies: Aim to gain a competitive advantage.
• Hacktivists: Have ideological motives.

These agents exploit vulnerabilities like weak encryption, insufficient data protection, and improper handling of user credentials. Mobile app developers and organizations must implement strong security measures, such as robust encryption, secure storage practices, and adherence to mobile security best practices, to mitigate these risks.

Attack Vectors

Exploitability: EASY

Insecure data storage in mobile applications exposes vulnerabilities to various attack vectors, including:

• Unauthorized access: Through physical or remote access to the device’s file system.
• Weak or absent encryption: Easy exploitation of unprotected data.
• Intercepting data transmissions: Especially when encryption is weak or absent.
• Malware or malicious apps: Installed on the device.
• Rooted or jailbroken devices: Allow attackers to bypass security measures.
• Social engineering: Deceiving users to gain access or manipulate app behavior.

These vectors highlight the need for robust encryption, secure transmission protocols, and comprehensive security measures during development.

Security Weakness

Prevalence: COMMON
Detectability: AVERAGE

Insecure data storage includes weaknesses that jeopardize data confidentiality and integrity:

• Weak or nonexistent encryption: Makes sensitive data easily accessible.
• Storing data in accessible locations: Such as plain text files or unprotected databases.
• Insufficient access controls: Allow unauthorized access to sensitive information.
• Lack of secure transmission protocols: Data can be intercepted during communication with external servers.

These weaknesses can lead to breaches, unauthorized access, and data tampering, underscoring the need for encryption, secure storage practices, and stringent access controls.

Technical Impact

Impact: SEVERE

Insecure data storage can have significant technical impacts, including:

• Data breaches: Sensitive information becomes susceptible to unauthorized access.
• Compromised user accounts: Insecure practices can expose login credentials and personal information.
• Data tampering: Without proper protection, attackers can modify stored data.
• Unauthorized access to resources: Attackers may access sensitive files or cryptographic keys.
• Reputation damage: Users may lose trust, reducing adoption and increasing legal risks.
• Compliance violations: Non-compliance with regulations can result in fines and penalties.

Business Impact

Impact: SEVERE

Insecure data storage can significantly impact business operations:

• Reputational damage: Data breaches lead to negative publicity and customer dissatisfaction.
• Loss of customer trust: Compromised data reduces loyalty and increases churn.
• Legal consequences: Non-compliance with regulations can result in fines and lawsuits.
• Financial implications: Costs of breach investigations, notifications, and legal settlements can be substantial.
• Competitive disadvantage: A poor security reputation can drive customers to competitors with stronger data protection practices.

Am I Vulnerable to Insecure Data Storage?

Common manifestations include:

• Lack of access controls: Allowing unauthorized users to access sensitive data.
• Inadequate encryption: Exposes data if storage is breached.
• Unintentional data exposure: Through logs, error messages, or debug features.
• Weak session management: Poor handling of tokens or authentication information.
• Insufficient input validation: Enabling attackers to manipulate data fields.
• Cloud storage misconfigurations: Exposing data due to improper permissions.
• Third-party vulnerabilities: Insecure libraries may lead to data leakage.
• Unintended data sharing: Improperly secured sharing features can expose sensitive data.

Preventing Insecure Data Storage

To protect sensitive data:

• Use strong encryption: Apply robust algorithms for data at rest and in transit.
• Secure data transmission: Use HTTPS and SSL/TLS protocols.
• Implement secure storage mechanisms: Utilize platform-specific tools like Keychain (iOS) and Keystore (Android).
• Apply strict access controls: Authenticate users securely and enforce permissions.
• Validate and sanitize inputs: Prevent injection attacks with rigorous validation.
• Manage sessions securely: Use strong tokens and enforce session timeouts.
• Update dependencies: Regularly patch libraries and frameworks.
• Stay informed: Monitor security advisories and updates for emerging threats.

Example Attack Scenarios

1. Storing passwords in plain text: Allows attackers to easily extract and exploit credentials.
2. Unsecured local storage: Sensitive data is accessible without encryption.
3. Insecure data caching: Exposed authentication tokens can be misused.
4. Unprotected logging: Sensitive data in logs can be intercepted.
5. Insecure cloud storage: Misconfigured permissions expose stored data.
6. Improper handling of temporary files: Failing to delete these leaves sensitive data exposed.

By addressing these vulnerabilities, organizations can significantly reduce the risk of insecure data storage and its associated impacts.

10. M10: Insufficient Cryptography

Threat Agents
Application-Specific

Threat agents who exploit insecure cryptography in mobile applications can compromise the confidentiality, integrity, and authenticity of sensitive information. These agents include attackers targeting cryptographic algorithms or implementations to decrypt sensitive data, malicious insiders who manipulate cryptographic processes or leak encryption keys, state-sponsored actors engaged in cryptanalysis for intelligence purposes, cybercriminals exploiting weak encryption to steal data or commit financial fraud, and attackers leveraging vulnerabilities in cryptographic protocols or libraries.

Attack Vectors
Exploitability: AVERAGE

The attack vector for insecure cryptography in a mobile application involves exploiting vulnerabilities in the cryptographic mechanisms designed to protect sensitive information. Adversaries may employ various techniques, such as cryptographic attacks, brute-force attacks, or side-channel attacks, to exploit weaknesses in encryption algorithms, key management, or implementation flaws. By targeting insecure cryptography, attackers aim to decrypt encrypted data, manipulate cryptographic processes, or gain unauthorized access to sensitive information. This can result in data breaches, unauthorized access to user accounts, compromised confidentiality, or the ability to forge or tamper with data.

Security Weakness
Prevalence: COMMON
Detectability: AVERAGE

Insecure cryptography in a mobile application introduces weaknesses that can undermine the effectiveness of cryptographic measures, compromising the confidentiality and integrity of sensitive data. These weaknesses include using weak encryption algorithms or inadequate key lengths, poor key management practices, improper handling of encryption keys, insecure random number generation, flawed implementation of cryptographic protocols, or vulnerabilities in cryptographic libraries or frameworks. Attackers can exploit these weaknesses to bypass encryption, perform cryptographic attacks, manipulate data, or gain unauthorized access to encrypted information. Insecure hash functions and cryptographic algorithms pose significant security weaknesses in mobile applications, potentially leading to serious data breaches. When outdated or weak hash functions are used, attackers can exploit these flaws to reverse-engineer hashed data, revealing the original content. To protect mobile applications from these security risks, it’s essential to adopt strong, modern hash functions and cryptographic algorithms, follow best practices in encryption and key management, and conduct regular security audits and updates to maintain the highest level of protection against potential threats.

Business Impacts
Impact: SEVERE

Insufficient cryptography or insecure hash functions in a mobile application can have significant business consequences. Some potential impacts include:

• Data Breach: Weak or insufficient cryptography makes it easier for attackers to compromise the confidentiality of sensitive data stored or transmitted by the mobile application. This can lead to a data breach, exposing sensitive customer information such as personally identifiable information (PII), financial details, or intellectual property. Such breaches can result in legal liabilities, regulatory penalties, loss of customer trust, and reputational damage.
• Loss of Intellectual Property: Inadequate cryptography can jeopardize the protection of proprietary algorithms, trade secrets, or other intellectual property embedded in the mobile application. If attackers decrypt and extract this valuable information, it could be exploited for competitive advantage or sold on the black market.
• Financial Losses: Insufficient cryptography can result in financial losses in various ways. For example, improperly encrypted payment transactions or financial data can expose customers to fraud and unauthorized access to their funds. Additionally, the costs associated with investigating and remediating security breaches, compensating affected customers, and addressing legal ramifications can be significant.
• Compliance and Legal Consequences: Many industries have specific data protection and privacy regulations that mandate the use of strong encryption for sensitive information. Inadequate cryptography may result in non-compliance with these regulations, leading to legal consequences, fines, or sanctions imposed by regulatory authorities.

Am I Vulnerable to ‘Insufficient Cryptography’?

Several vulnerabilities related to insecure cryptography and insecure hash functions may manifest in a mobile application:

• Weak Encryption Algorithms: The mobile app may use encryption algorithms that are known to be weak or vulnerable to attacks. These algorithms may have known weaknesses, be outdated, or lack the necessary level of security to protect sensitive data effectively.
• Insufficient Key Length: Short or easily guessable encryption keys weaken encryption strength. If a mobile app uses such keys, attackers may decrypt the data through brute-force or other cryptographic attacks.
• Improper Key Management: Poor key management practices, such as storing encryption keys insecurely or transmitting them in plain text, expose keys to unauthorized access. Attackers who gain access to these keys can decrypt the data without difficulty.
• Flawed Encryption Implementation: Errors in the encryption or decryption process may introduce vulnerabilities that attackers can exploit to weaken or bypass encryption protections.
• Insecure Storage of Data/Encryption Keys: Storing encryption keys insecurely on the mobile device—such as in plain text or in easily accessible locations—makes it easier for attackers with physical or unauthorized access to retrieve the keys and decrypt protected data.
• Lack of Secure Transport Layer: When transmitting encrypted data over networks, secure transport protocols like HTTPS are essential. Failure to implement secure transport protocols can make encrypted data vulnerable to interception or tampering during transmission.
• Insufficient Validation and Authentication: Inadequate validation and authentication mechanisms can weaken overall security. Without proper validation, attackers can impersonate legitimate entities, intercept encrypted data, and manipulate it without detection.
• Lack of Salting: The process of adding random data to the input before hashing (salting) enhances password security. Insecure hash functions may fail to support salting or use weak salting methods, making password hashes vulnerable to attacks such as pre-computed tables or brute-force attacks.

How Do I Prevent ‘Insufficient Cryptography’?

To prevent “insufficient cryptography” vulnerabilities in a mobile application, consider the following best practices:

• Use Strong Encryption Algorithms: Implement widely accepted and secure encryption algorithms, such as AES (Advanced Encryption Standard), RSA (Rivest-Shamir-Adleman), or Elliptic Curve Cryptography (ECC). Stay updated with current cryptographic standards and avoid deprecated or weak algorithms.
• Ensure Sufficient Key Length: Select encryption keys with appropriate lengths to ensure strong cryptographic strength, following industry recommendations based on the specific encryption algorithm.
• Follow Secure Key Management Practices: Use key vaults or hardware security modules (HSMs) to securely store encryption keys. Protect keys from unauthorized access, including limiting access to authorized personnel, encrypting keys at rest, and using secure key distribution mechanisms.
• Implement Encryption Correctly: Adhere to established cryptographic libraries and frameworks to implement encryption and decryption processes in the mobile application. Avoid custom encryption implementations, as they may introduce errors and vulnerabilities.
• Secure Storage of Encryption Keys: Ensure that encryption keys are securely stored on the mobile device, avoiding storage in plain text or easily accessible locations. Use secure storage mechanisms provided by the operating system or hardware-based secure storage options.
• Employ Secure Transport Layer: Use secure transport protocols like HTTPS for transmitting encrypted data over networks. Validate certificates and ensure secure communication channels between the mobile app and backend systems.
• Validate and Authenticate: Implement strong validation and authentication mechanisms to verify the integrity and authenticity of entities involved in the encryption process. Validate certificates, digital signatures, or other authentication mechanisms.
• Regularly Update Security Measures: Stay informed about security updates, patches, and recommendations from cryptographic libraries, frameworks, and platform providers. Keep the mobile application and cryptographic components up to date to address identified vulnerabilities.
• Conduct Security Testing: Perform thorough security testing, including cryptographic vulnerability assessments, penetration testing, and code reviews. Identify and fix weaknesses or vulnerabilities discovered during the testing process.
• Follow Industry Standards and Best Practices: Stay updated with industry standards and best practices related to cryptography. Organizations like NIST (National Institute of Standards and Technology) and IETF (Internet Engineering Task Force) provide guidelines for secure cryptographic practices.
• Use Strong Hash Functions: Choose cryptographically secure hash functions like SHA-256 or bcrypt, which are designed to resist attacks and provide a high level of security.
• Implement Salting: Always use a strong random salt when hashing passwords to make it harder for attackers to use precomputed tables or rainbow tables.
• Use Key Derivation Functions (KDFs): For password hashing, use KDFs like PBKDF2, bcrypt, or scrypt. These functions are designed to securely derive cryptographic keys from passwords and provide added security features, such as iteration counts to slow down brute-force attacks.

Example Attack Scenarios

• Scenario #1: Man-in-the-Middle (MitM) Attacks
  An attacker intercepts communication between the mobile application and the server. Weak cryptography allows attackers to decrypt, modify, and re-encrypt the data before forwarding it, leading to unauthorized access, data manipulation, or malicious content injection.
• Scenario #2: Brute-Force Attacks
  Attackers systematically try different combinations of keys until the correct one is found to decrypt the data. Weak cryptography shortens the time required for such attacks, potentially exposing sensitive information.
• Scenario #3: Cryptographic Downgrade Attacks
  If mobile applications support multiple encryption protocols, attackers can exploit weak cryptography as a fallback option, forcing the application to use weaker encryption. This allows them to decrypt intercepted data more easily and launch further attacks.
• Scenario #4: Key Management Vulnerabilities
  Weak key management practices, such as storing keys insecurely or making them easily guessable, allow attackers to gain unauthorized access to keys and decrypt encrypted data, resulting in data breaches and privacy violations.
• Scenario #5: Crypto Implementation Flaws
  Weak cryptography can stem from implementation flaws within the application, such as improper handling of padding schemes or poor random number generation. These flaws can lead to vulnerabilities that attackers can exploit to break the encryption and access sensitive data.

Final Words:

The OWASP Mobile Top 10 2024 is a crucial resource for securing mobile applications in an era where mobile usage dominates digital interactions. By understanding and addressing these top threats, organizations can protect user data, maintain regulatory compliance, and foster trust with their users. Prioritizing mobile security is no longer optional—it’s a necessity.

Application security is a continuous effort. Conducting regular security assessments, thorough code reviews, and comprehensive employee training are crucial to maintaining a robust security posture. Furthermore, taking a proactive stance on threat modeling and integrating security throughout the software development lifecycle (SDLC) can strengthen an organization’s defenses against emerging cyber threats. 

Strobes helps to secure your data by conducting continues threat exposure management (CTEM) which helps to strengthen your organization defence againest vulnerabilities. Start your free trail today.