return
OWASP Mobile Top 10 is a list compiled by the Open Web Application Security Project (OWASP), a non-profit security community focused on improving software security. This list identifies and describes the ten most critical and common vulnerabilities affecting mobile applications. The purpose of the OWASP Mobile Top 10 is to raise awareness of mobile security threats and provide guidance to developers, security professionals and organizations to mitigate these risks.
Each vulnerability in the list is detailed with a description, indicators that may indicate its presence, mitigation recommendations and examples of related attacks. These vulnerabilities cover a wide range of security issues ranging from poor authentication and authorization, to insecure data storage and insufficient cryptographic protection. The OWASP Mobile Top 10 has been updated in 2024, after 8 years and reflects the latest trends and challenges in the field of mobile security, thus providing valuable guidance for the application development community.
Vulnerability M1: Improper Credential Usage
Vulnerability M1, "Improper Credential Usage", refers to inappropriate practices related to credential management and storage in mobile applications. This vulnerability can arise when credentials (such as usernames, passwords, authentication tokens, etc.) are not handled securely, exposing them to potential attackers.
Risk indicators
• Insecure storage: Credentials are stored in plain text on the device's file system, in unencrypted databases or in unprotected shared preferences.
• Insecure transmission: Credentials are sent over the network unencrypted (e.g., using HTTP instead of HTTPS)..
• Improper session handling: Sessions are not properly invalidated when logging out, allowing an attacker to reuse session tokens.
• Use of obsolete authentication mechanisms: Use of weak encryption algorithms or authentication methods that have been compromised.
Recommended mitigations
• Use secure storage provided by the operating system (e.g. Keychain on iOS, Keystore on Android).
• Avoid storing credentials in plain text or in unsecured locations.
• Encrypt all communications containing credentials using TLS/SSL.
• Implement HTTPS with secure configurations and valid certificates.
• Invalidate session tokens at logout.
• Use session tokens with appropriate expiration and revocation times.
• Implement secure token renewal mechanisms.
• Use multi-factor authentication (MFA) whenever possible.
• Employ strong, up-to-date encryption and hashing algorithms.
• Do not reuse credentials in different services or applications.
Examples of attacks
Unsafe storage:
An attacker with physical access to the device or through an exploit can access a plain text file containing unencrypted stored credentials, thereby gaining unauthorized access to the application or associated services.
Traffic interception:
If an application transmits credentials over HTTP, an attacker who can intercept network traffic (e.g., via a man-in-the-middle attack) can capture the credentials and use them to access the application.
Session hijacking:
If session tokens are not properly invalidated at logout, an attacker who obtains a valid token (e.g., through an XSS attack) can reuse it to access the user's session without needing to know the user's credentials.
Obsolete authentication:
Using weak hashing algorithms such as MD5 to store passwords can allow an attacker who obtains the password database to crack passwords with relative ease using brute force or dictionary attacks.
Vulnerability M2: Inadequate Supply Chain Security
Vulnerability M2, "Inadequate Supply Chain Security," refers to risks associated with the software supply chain in mobile application development. This includes the use of third-party components, libraries, frameworks and external services that are not adequately verified or maintained. The security of an application can be compromised if any of these elements contain vulnerabilities, are compromised or intentionally include malicious code.
Risk indicators
• Use of obsolete or unmaintained libraries: Integration of software components that do not receive regular security updates.
• Lack of component verification: Failure to perform adequate checks on the integrity and authenticity of third-party components used.
• Lack of continuous monitoring: Vulnerabilities of external components used in the application are not actively monitored.
• Lack of security policies: Lack of clear policies and procedures to assess and manage risks in the software supply chain.
Recommended mitigations
• Use digital signatures and hashes to verify the integrity and authenticity of software components.
• Download components only from trusted and verified sources.
• Keep all third-party components used in the application up to date.
• Regularly monitor vulnerability databases (such as NVD) to detect known problems in the components used.
• Conduct periodic security assessments and penetration tests to identify vulnerabilities in third-party components.
• Establish an evaluation and approval process for the integration of new components.
• Implement clear security policies that address the selection, evaluation and use of third-party components.
• Foster a safety culture that values the importance of a safe supply chain.
Examples of attacks
Injection of malicious code into libraries:
An attacker compromises a popular library used by many developers. Applications that integrate this library without verifying its integrity may include malicious code that allows the attacker to execute arbitrary code on users' devices.
Use of vulnerable components:
An application uses an outdated version of an encryption library that has a known vulnerability. An attacker can exploit this vulnerability to decrypt sensitive data transmitted or stored by the application.
Supply chain attacks:
A third-party software vendor is compromised, and the attacker injects malware into a software update. Developers who integrate this update without performing proper checks can inadvertently distribute malware to end users.
Unverified units:
A developer includes an open source library without verifying its origin or security history. The library contains a backdoor that allows an attacker to remotely access the application and user data.
M3 Vulnerability: Insecure Authentication/Authorization
The M3 vulnerability, "Insecure Authentication/Authorization", refers to flaws in the authentication and authorization mechanisms of a mobile application. This includes any weaknesses in how users authenticate to the application and how their permissions and access to different resources within the application are handled. Deficiencies in these mechanisms can allow attackers to impersonate identities, gain unauthorized access to resources and data, or escalate privileges.
Risk indicators
• Session tokens that do not expire or are not properly invalidated at logout.
• Sessions that do not close automatically after a period of inactivity.
• Use of easy-to-guess passwords or passwords without minimum security requirements.
• Absence of multi-factor authentication (MFA).
• Do not limit the number of failed login attempts.
• Transmission of unencrypted credentials.
• Storage of credentials in plain text on the device.
• Lack of adequate control of access to resources and functionalities.
• Users who can escalate privileges due to insufficient controls.
Recommended mitigations
• Implement multi-factor authentication (MFA) to add an extra layer of security.
• Require strong passwords and enforce periodic password change policies.
• Limit the number of failed login attempts and temporarily lock accounts after multiple failed attempts.
• Use secure session tokens and set them to expire after a period of inactivity.
• Ensure that session tokens are properly invalidated when logging out.
• Implement secure cookies with HttpOnly and Secure flags to protect session tokens.
• Encrypt credentials during transmission using HTTPS.
• Use the operating system's secure storage (Keychain on iOS, Keystore on Android) to store credentials.
• Implement granular access controls based on roles and permissions.
• Perform authorization checks on the server for all sensitive operations.
• Avoid relying solely on client-side authorization controls.
Examples of attacks
Brute force:
An attacker attempts to log in to the application with multiple username and password combinations, taking advantage of the lack of login attempt limitation. If the application does not have brute force protection, the attacker can eventually guess the correct credentials.
Session hijacking:
If an application does not properly invalidate session tokens at logout, an attacker who obtains a valid session token (e.g., through an XSS attack) can reuse it to access the user's account.
Escalation of privileges:
An attacker with access to a normal user account can exploit flaws in authorization controls to gain access to functionality or data reserved for administrators or users with higher privileges.
Phishing and man-in-the-middle attacks:
If credentials are transmitted unencrypted, an attacker can intercept communications and capture credentials using a man-in-the-middle attack. He can also trick users into entering their credentials on a fake website using phishing techniques.
Vulnerability M4: Insufficient Input/Output Validation
Vulnerability M4, "Insufficient Input/Output Validation," refers to the failure to properly validate data being received and sent in a mobile application. This includes failing to properly validate or sanitize user input data, API responses, data received from other applications, or data stored and processed internally. Insufficient validation can allow attackers to inject malicious data, manipulate application behavior, and access sensitive data.
Risk indicators
• Form fields that accept any type of data without restrictions.
• No checks are performed on limits, formats, data types or characters allowed in the data entered by the user.
• Data sent to the browser or other applications without being sanitized, which may allow the injection of malicious scripts or commands.
• API responses that are not validated before being processed by the application.
• Data displayed to the user without being filtered or sanitized.
• Lack of validation in interactions between applications.
• Data received from other applications that are not validated before use.
Recommended mitigations
• Implement robust client-side and server-side validations for all user input.
• Use whitelists to define the formats and types of data allowed.br>
• Verify limits, ranges and sizes of data entered.
• Use secure libraries and functions to validate input data.
• Sanitize all data before displaying it to the user or sending it to other applications.
• Correctly escape special characters to avoid script or command injections.
• Validate and sanitize responses received from APIs before processing or displaying them to the user.
• Implement additional security controls for interactions with external APIs.
• Validate data received from other applications before use.
• Establish secure communication protocols and validate the authenticity of data sources.
Examples of attacks
SQL Injection:
If an application does not properly validate input data and allows a user to enter malicious data into a form field, an attacker can execute unauthorized SQL commands that compromise the database.
Cross-Site Scripting (XSS):
If an application displays user-entered data without sanitizing it, an attacker can inject malicious scripts that execute in the user's browser, allowing the theft of cookies, credentials and other sensitive data.
Command injection:
If a mobile application allows input data to be passed directly to the operating system command line without validation, an attacker can execute arbitrary commands on the device.
API data manipulation:
If an application does not validate external API responses before processing them, an attacker who controls the API or intercepts communications can send malicious data that alters the application's behavior or exposes sensitive data.
Vulnerability M5: Insecure Communication
Vulnerability M5, "Insecure Communication", refers to the lack of adequate protection of data transmitted between the mobile application and its backend servers or between the application and other services. This lack of protection can allow attackers to intercept, modify or eavesdrop on the transmitted data. Insecure communications can expose sensitive data, such as user credentials, personal information, or financial data, to potential attackers.
Risk indicators
• Data transmission over HTTP instead of HTTPS.
• Use of outdated and vulnerable versions of security protocols (e.g. SSL 2.0/3.0, TLS 1.0/1.1).
• Failure to properly validate SSL/TLS certificates.
• Use of self-signed certificates without adequate validation mechanisms.
• Sending or receiving sensitive data without encryption.
• Temporary storage of data in plain text during transmission.
• Failure to implement measures to detect and prevent Man-in-the-Middle attacks.
• Failure to use server and client identity assurance mechanisms.
Recommended mitigations
• Use HTTPS instead of HTTP for all communications.
• Implement modern and secure versions of TLS (such as TLS 1.2 or TLS 1.3).
• Properly validate the server's SSL/TLS certificates.
• Use certificates issued by trustworthy certification authorities.
• Implement certificate pinning to ensure that the application only communicates with trusted servers.
• Encrypt all sensitive data both in transit and at rest.
• Use strong, up-to-date encryption algorithms (such as AES with an appropriate key size).
• Implement detection of changes in certificates and alerts about possible Man-in-the-Middle attacks.
• Use techniques such as HSTS (HTTP Strict Transport Security) to force the use of HTTPS.
• Implement mutual authentication (client-side certificates) to ensure that both client and server can verify each other's identity.
Examples of attacks
Traffic interception (sniffing):
An attacker can use tools such as Wireshark to intercept unencrypted HTTP traffic and obtain sensitive information such as usernames, passwords or personal data.
Man-in-the-Middle attacks:
An attacker can intercept the communication between the mobile application and the server by presenting a fake SSL certificate. If the application does not validate the certificates correctly, the attacker can decrypt and modify the traffic at will.
Downgrade attacks:
An attacker can force the application to use older and vulnerable versions of security protocols (such as SSL 3.0), exposing the communication to known vulnerabilities.
Injection of malicious content:
If the communication is not encrypted, an attacker can modify the data in transit, injecting malicious commands, scripts or redirecting users to phishing sites.
Vulnerability M6: Inadequate Privacy Controls
Vulnerability M6, "Inadequate Privacy Controls," refers to the lack of adequate measures to protect the privacy of users' personal data in mobile apps. This can include excessive data collection, insecure storage of personal data, lack of adequate consent, and lack of transparency about how data is handled and shared. This vulnerability can lead to privacy breaches, exposure of sensitive data and potential legal issues.
Risk indicators
• The application requests permissions to access more information than is necessary for its operation.
• Collection of sensitive data without clear justification or functional necessity.
• The user's explicit consent is not requested before collecting and processing their personal data.
• Unclear or difficult to understand terms of service and privacy policies.
• Storage of personal data without encryption.
• Transmission of personal data without using secure connections (such as HTTPS).
• Users cannot access, modify or delete their personal data.
• Lack of options for users to limit data collection.
• Personal data shared with third parties without adequately informing users.
• It is not specified with whom the data is shared and for what purpose.
Recommended mitigations
• Collect only the data necessary for the operation of the application.
• Evaluate and justify each request for permission or collection of sensitive data.
• Request explicit and specific consent from users before collecting and processing their personal data.
• Provide clear, accessible and easy to understand terms of service and privacy policies.
• Encrypt personal data both at rest and in transit.
• Use secure connections (such as HTTPS) for data transmission.
• Provide users with options to access, modify and delete their personal data.
• Implement privacy controls that allow users to limit the collection and use of their data.
• Clearly inform users about what data is collected, how it is used and with whom it is shared.
• Establish and communicate clear policies on data sharing with third parties.
Examples of attacks
Exposure of sensitive data:
An application that stores personal data without encryption can be exploited by an attacker who gains access to the device or database, exposing sensitive information such as names, addresses, phone numbers, etc.
Lack of informed consent:
An application that collects location data in the background without the user's explicit consent may be violating the user's privacy, potentially allowing unauthorized tracking and surveillance.
Interception of personal data:
If an application transmits personal data over an unsecured connection (HTTP instead of HTTPS), an attacker intercepting the traffic can capture sensitive information, such as login credentials, financial data, etc.
Improperly shared data:
An application that shares personal data with third parties without properly informing users can lead to the exploitation of that data by advertisers, data brokers or even malicious actors, compromising user privacy.
Vulnerability M7: Insufficient Binary Protections
The M7 vulnerability, "Insufficient Binary Protections," refers to the lack of adequate measures to protect the binary code of a mobile application against analysis, manipulation and reverse engineering. These protections are crucial to prevent attackers from obtaining sensitive information, discovering vulnerabilities in the app or modifying its behavior to perform malicious activities.
Risk indicators
• The binary code is not obfuscated, which facilitates analysis and reverse engineering.
• Integrity checks are not implemented to detect unauthorized modifications to the application code.
• Debugging tools and settings not disabled in the production version of the application.
• No techniques are used to hinder the use of analysis and decompilation tools.
• Sensitive information, such as encryption keys and credentials, stored directly in the binary code.
Recommended mitigations
• Use obfuscation tools to make binary code more difficult to understand and analyze.
• Obfuscate both native code and Java/Kotlin code in Android apps, and Swift/Objective-C in iOS apps.
• Implement integrity checks at runtime to detect and respond to unauthorized code modifications.
• Use hashes and digital signatures to verify the integrity of binaries.
• Ensure that debugging options and development tools are disabled in production versions of the application.
• Use techniques such as anti-debugging to detect and prevent the use of debuggers in the application.
• Use techniques to make it difficult to use analysis and decompilation tools, such as packaging native code and using secure execution environments.
• Implement emulator detection and static analysis environments.
• Avoid storing encryption keys, credentials and other sensitive information directly in the binary code.
• Use the secure storage provided by the operating system (Keychain on iOS, Keystore on Android) to handle sensitive information.
Examples of attacks
Reverse engineering:
An attacker uses tools such as Apktool to decompile an Android application and analyze its code. Without proper protections, the attacker can identify vulnerabilities, extract sensitive information or modify the app's behavior for his own benefit.
Binary modification:
An attacker modifies the binary code of an application to remove security features, such as authentication checks, and redistribute the modified application. This can allow unauthorized use of the application or exploitation of vulnerabilities.
Extraction of encryption keys:
An attacker analyzes the binary code of an application to extract encryption keys stored in plaintext. With these keys, the attacker can decrypt sensitive data, compromising the user's privacy and security.
Use of debugging tools:
If an application does not disable debugging options in the production version, an attacker can use debugging tools to intercept and modify the application's execution flow, allowing vulnerabilities to be exploited or data to be manipulated.
M8 Vulnerability: Security Misconfigurations
Vulnerability M8, "Security Misconfiguration," refers to the misconfiguration of security components in a mobile application or its environment. This can include insecure default configurations, excessive permissions, debugging options enabled in production, and errors in backend server configuration. Misconfigurations can allow attackers to exploit weaknesses in the application, accessing sensitive data or compromising its operation.
Risk indicators
• Use of default settings that are not secure by default.
• Do not change the default passwords of databases, servers or services.
• The application requests more permissions than necessary for its operation.
• The principle of least privilege does not apply to access configurations.
• Debugging options or detailed logs enabled in the production version.
• Exposure of sensitive information through logs or detailed error messages.
• Backend servers configured without HTTPS.
• Security settings such as Content Security Policy (CSP) or protection against XSS attacks are missing.
• Failure to keep application and server components up to date.
• Use of deprecated and vulnerable versions of libraries or frameworks.
Recommended mitigations
• Review and secure all default settings before deploying the application.
• Change default passwords and secure service access settings.
• Request only the permissions strictly necessary for the operation of the application.
• Apply the principle of least privilege in all access configurations.
• Make sure that debugging options and detailed logs are disabled in the production version.
• Use appropriate logs that do not expose sensitive information.
• Use HTTPS for all communications between the application and the servers.
• Implement security policies such as CSP, XSS protection, and input validation.
• Apply updates and security patches regularly.
• Use updated and secure versions of libraries and frameworks.
Examples of attacks
Exploitation of default configurations:
An attacker can access an application's database because the default passwords were left unchanged. This allows the attacker to access sensitive data stored in the database.
Excess of permits:
A mobile app that requests permissions to access location, contacts and camera, without functional need, exposes more user data than it should. An attacker exploiting a vulnerability in the app can access this excessive data.
Debugging options enabled in production:
If an application has debugging options enabled, an attacker can obtain detailed information about the inner workings of the application, including possible entry points for exploits.
Lack of HTTPS in communications:
An application that communicates with its backend server via HTTP allows an attacker to perform a Man-in-the-Middle attack to intercept and manipulate transmitted data, including user credentials and other sensitive data.
Updates and patches not applied:
An application using an outdated vulnerable library can be exploited by an attacker to execute malicious code or compromise data. Known vulnerabilities can be easily exploited if available security patches are not applied.
Vulnerability M9: Insecure Data Storage
Vulnerability M9, "Insecure Data Storage," refers to the lack of adequate measures to protect data stored on a mobile device. This vulnerability can allow attackers to access sensitive data, such as user credentials, personal information and financial data, if they manage to compromise the device or access its storage files.
Risk indicators
• Sensitive data stored unencrypted in the device's local storage.
• Use of storage APIs that do not provide encryption or adequate security measures.
• Sensitive data recorded in accessible log files.
• Local databases that do not implement encryption for stored sensitive data.
• Sensitive data files that do not have appropriately restricted access permissions.
Recommended mitigations
• Use strong encryption (such as AES) for all sensitive data stored locally.
• Implement encryption both at rest and in transit.
• Employ the secure storage APIs provided by the operating system (e.g. Keychain on iOS and Keystore on Android).
• Avoid using unsecured external storage for sensitive data.
• Store as little sensitive data locally as possible.
• Consider whether it is necessary to store certain data on the device.
• Avoid recording sensitive data in log files.
• Ensure that logs are protected and accessible only to authorized users.
• Set appropriate file permissions to restrict access to sensitive data.
• Use operating system access control mechanisms to protect files.
Examples of attacks
Access to plain text data:
If an application stores user credentials in plain text in local storage, an attacker who gains physical access to the device or manages to compromise it through malware can read this data without the need to decrypt anything.
Exploitation of insecure storage APIs:
An application that uses a storage API without proper encryption can allow an attacker to easily access stored data through malicious applications or data analysis tools.
Log data extraction:
If an application records sensitive data, such as authentication tokens, in log files, an attacker who has access to these files can steal this data and compromise user accounts.
Compromise of unencrypted local databases:
If an application stores personal information in an unencrypted SQLite database, an attacker who gains access to the database file can read all the information without additional authentication.
Access to files with inappropriate permissions:
If files containing sensitive data have overly broad access permissions, any application or device user can access them. This can lead to exposure of critical information.
Vulnerability M10: Insufficient Cryptography
Vulnerability M10, "Insufficient Cryptography," refers to the inadequate or weak use of encryption techniques in a mobile application to protect sensitive data. This can include the use of weak encryption algorithms, improper implementation of encryption, and failure to adequately protect keys and sensitive data. Inadequate cryptographic implementation can allow attackers to access, modify or compromise sensitive data, compromising the security of the application and the privacy of users.
Risk indicators
• Implementation of obsolete or weak encryption algorithms, such as DES or RC4.
• Use of weak or predictable encryption keys, such as simple passwords or passwords derived from easily accessible information.
• Sensitive data stored or transmitted without encryption or with insufficient encryption.
• Insecure storage of encryption keys, such as storing them in plaintext or unsecured storage.
• Improper implementation of security protocols, such as SSL/TLS, which may allow man-in-the-middle attacks or expose sensitive data.
Recommended mitigations
• Use modern and secure encryption algorithms, such as AES, to protect sensitive data.
• Avoid obsolete or weak algorithms.
• Generate robust and random encryption keys using secure cryptographic functions.
• Avoid using passwords or predictable patterns for key generation.
• Encrypt all sensitive data both at rest and in transit using strong encryption algorithms.
• Use reliable and well-tested cryptographic libraries to implement encryption.
• Store encryption keys securely using mechanisms such as Keychain on iOS or Keystore on Android.
• Avoid storing keys in plain text or in places accessible to unauthorized applications.
• Configure and use security protocols such as SSL/TLS properly and securely.
• Enable secure configuration options, such as end-to-end encryption and certificate validation, to protect communications.
Examples of attacks
Brute force attacks on weak keys:
An attacker can perform a brute force attack against a weak or predictable encryption key to decrypt sensitive data stored or transmitted by the application.
Dictionary attacks on poorly protected passwords:
If an application stores user passwords using weak encryption or without adequate protection, an attacker can use a dictionary attack to crack passwords and gain unauthorized access to user accounts.
Man-in-the-Middle attacks on unsecured communications:
If an application transmits sensitive data unencrypted or with weak encryption, an attacker who can intercept the communication can read and modify the data, compromising the confidentiality and integrity of the information.
Exploitation of unprotected stored encryption keys:
If encryption keys are stored insecurely, such as in plain text in a configuration file, an attacker who gains access to these keys can decrypt sensitive data stored or transmitted by the application.
Exploitation of misconfigured security protocols:
If an application uses security protocols such as SSL/TLS incorrectly or insecurely, an attacker can exploit weaknesses in the configuration to perform man-in-the-middle attacks and compromise communications.
Conclusion
These vulnerabilities represent a wide range of security risks that can affect mobile applications. From fundamental issues such as improper credential handling and lack of authentication, to critical failures in the storage and transmission of sensitive data, these vulnerabilities jeopardize the privacy, integrity and security of mobile applications and user data.
To effectively address these vulnerabilities, it is crucial to implement a combination of technical security measures and secure development processes. This includes adopting good encryption practices, proper use of encryption and authentication, implementing appropriate access controls, conducting thorough security testing, and training staff on security issues.
By taking proactive steps to identify, remediate and mitigate these vulnerabilities, organizations can significantly improve the security of their mobile applications, thereby protecting both users and sensitive data. Continued awareness of mobile security threats and commitment to security best practices are essential to ensure a secure and reliable mobile experience for all users.
