Sign Up Login
Resource Center  >  Blog

OWASP Mobile Top 10 Vulnerabilities and How to Prevent Them

July 6, 2022
Oliver Moradov

What Is OWASP Mobile Top 10?

The Open Web Application Security Project (OWASP) foundation provides security insights and recommendations for software security. The OWASP Top Ten Web Application Security Risks list is used by many in the industry to prioritize security vulnerabilities. In addition to this list, OWASP also identifies security vulnerabilities and risks in mobile applications.

The OWASP Mobile Top 10 list includes security vulnerabilities in mobile applications and provides best practices to help remediate and minimize these security concerns. This list is critical to help prioritize security vulnerabilities in mobile applications and build appropriate defenses that can handle static attacks based on source code and dynamic attacks that exploit application functionality. 

Check out the official page for the Mobile Top 10.

Related content: See our guides to other OWASP Top 10 lists:

  • OWASP Web Application Top 10 (coming soon)
  • OWASP API Top 10 (coming soon)

In this article:

OWASP Mobile Security Top 10 and Preventive Measures

M1: Platform Misuse 

The improper usage of Android and iOS platforms is a leading threat, with many applications unintentionally violating the relevant security guidelines and best practices. Misuse extends to any feature of the platform or failure to implement security controls. 

It is possible to prevent this vulnerability by remediating server-side features and implementing these steps:

  • Adhere to the platform development best practices and guidelines. 
  • Use secure configuration and coding to harden the server-side. 
  • Restrict applications from transmitting user data.
  • Restrict file access permissions.
  • Encrypt and store data securely.

M2: Lack of Data Storage Security

Improper data storage is another major vulnerability because attackers can easily exploit stolen devices and exfiltrate sensitive data. Sometimes an application must store data, but this data must remain in a secure location that other applications or individuals cannot access. 

Here are practices for storing data securely:

  • Keep data encrypted.
  • Use an access authorization mechanism in the mobile application.
  • Restrict the application’s access to stored data. 
  • Use secure coding practices to prevent buffer overflow and data logging.

M3: Unsafe Communications

Transmitting data to or from mobile applications usually involves the Internet or a telecommunications carrier. Attackers can intercept data in transit via compromised networks. 

Here are practices to ensure secure communications:

  • Use SSL/TLS certificates for secure transmission.
  • Use signed and trusted CA certificates.
  • Use encryption protocols.
  • Send sensitive data to a back end API.
  • Avoid sending user IDs with SSL session tokens.
  • Implement encryption before SSL channel transmission.

M4: Authentication Issues

Mobile devices sometimes fail to identify users, allowing malicious actors to log in using default credentials. Attackers can often bypass authentication protocols due to poor implementation, directly interacting with the server. 

To ensure secure authentication:

  • Use the right authentication method (i.e., server-side mechanism). 
  • Avoid storing passwords on local and user devices.
  • Avoid persistent authentication functionalities and display caution signals if users opt for them.
  • Use device-based authentication to prevent users from accessing data from other devices.
  • Implement binary attack protection.

M5: Lack of Cryptography

Without sufficient cryptography, attackers can revert sensitive data to the original state and enable unauthorized access. This vulnerability is usually easy to exploit. 

To ensure strong encryption:

  • Avoid storing data on mobile devices.
  • Use robust cryptography algorithms.

M6: Insufficient Authorization

Without sufficient authorization measures, intruders can access sensitive data and escalate privileges to expand their attacks. Insecure direct object reference (IDOR) allows attackers to access files, accounts, and databases. The app is insecure if the authorization mechanism fails to verify users and grant permissions. 

To ensure secure authorization:

  • Avoid granting access permissions and roles via mobile devices.
  • Verify identities independently via back end code.

M7: Poor-Quality Client Code 

Poor coding practices can result in vulnerable code. The risk is especially high when team members use different coding techniques and fail to collaborate or provide sufficient documentation. Detecting this vulnerability is challenging because hackers must be aware of the poor coding practices.

To ensure the quality of client code:

  • Enforce good coding practices with consistent patterns across the organization.
  • Perform static code analysis.
  • Use complex logic code.
  • Securely integrate external libraries.
  • Use automated tools to test memory leaks, buffer overflow, and code execution.

M8: Manipulated Code 

App stores often contain manipulated versions of mobile applications, such as apps with modified binaries, including malicious content or backdoors. Attackers can deliver these counterfeit applications directly to the victim via phishing or publish them on app stores. 

To prevent attackers from tampering with code:

  • Inspect the code for test keys, OTA certificates, rooted APKs, and SU binaries.
  • Look for the in the build.prop to see if it’s an unofficial ROM or developer build.
  • Attempt commands directly (i.e., SU commands).
  • Set up alerts for code integration and respond accordingly to incidents.
  • Implement anti-tampering measures like validation, code hardening, and digital signatures.

M9: Reverse Engineering Attacks

Attackers can reverse engineer applications and perform code analysis—this is especially dangerous because attackers can inspect and modify the code to inject malicious functionalities. Reverse engineering allows attackers to understand how an application operates, allowing them to recompile it. 

To protect mobile applications from reverse engineering:

  • Check if it’s possible to decompile the application.
  • Use debugging tools to run the application from an attacker’s perspective.
  • Ensure robust obfuscation (including for metadata).
  • Develop the application using C or C++ to protect the code.
  • Use binary packaging to prevent attackers from decompiling code.
  • Block debugging tools.

M10: Redundant Functionality

Attackers can examine mobile applications via log and configuration files, identifying and exploiting redundant functionalities to access the back end. For example, an attacker might anonymously execute privileged actions. Manual code reviews before release help mitigate this risk.

To identify and eliminate redundant functionality:

  • Inspect the application’s configurations for hidden switches.
  • Check that the log statement and API endpoints are not publicly exposed. 
  • Check if the app’s accessible API endpoint is properly documented.
  • Check if the log contains content exposing privileged accounts or back end server processes. 

Mobile Application Security with Bright

Start detecting the technical OWASP Mobile Top 10 and more, seamlessly integrated across your pipelines via:

  • Bright Security Rest API
  • Convenient CLI for developers
  • Common DevOps tools like CircleCI, Jenkins, JIRA, GitHub, Azure DevOps, and more

Learn more about Bright Security

Related Articles:

Related topics

Dynamic Application Security Testing (DAST) is a crucial component in fortifying web applications against potential vulnerabilities. By taking a proactive stance, DAST systematically detects and addresses security flaws.

See more

By mapping Dynamic Application Security Testing (DAST) to the Payment Card Industry Data Security Standard (PCI DSS) requirements, organizations can

See more

What Is Mobile Application Security Testing?  Mobile application security testing is the process of assessing, analyzing, and evaluating the security

See more

Test Your Web App for 10,000+ Attacks

See Our Dynamic Application Security Testing (DAST) in Action

  • Find & fix vulnerabilities fast
  • Zero false positives
  • Developer friendly

and see how easy AppSec can be

Test Your Web App for 10,000+ Attacks

Integrate vulnerability testing into your DevOps pipeline. Find & fix vulnerabilities fast with zero false positives.
See Our Dynamic Application Security Testing (DAST) in Action
Testing variance Using Legacy Dast Using Dev-Centric Dast
% of orgs knowingly pushing vulnerable apps & APIs to prod 86% 50%
Time to remediate >Med vulns in prod 280 days <150 days
% of > Med vulns detected in CI, or earlier <5% ~55%
Dev time spent remediating vulns - Up to 60x faster
Happiness level of Engineering & AppSec teams - Significantly improved
Average cost of Data Breach (US) $7.86M $7.86M