DEV Community

Cover image for OWASP Top 10 Mobile Vulnerabilities Developers Need to Understand
Joy Winter
Joy Winter

Posted on

OWASP Top 10 Mobile Vulnerabilities Developers Need to Understand

With the growing number of mobile apps, it’s imperative that mobile developers stay vigilant about security vulnerabilities and have the know-how to mitigate them. With the OWASP mobile top 10 vulnerabilities, developers can learn how to maintain the security of their mobile apps to protect them from cyberattacks.

Open Web Application Security Project (OWASP) is a community-based foundation that focuses on spreading awareness about software and application security. OWASP organizes several leading training and education programs in the field of cybersecurity as well.

Let’s take a closer look at the OWASP top 10 mobile app vulnerabilities.

Which Are the OWASP Top 10 Mobile App Vulnerabilities?

Understanding these security vulnerabilities will help you assess your mobile app better and maintain strong security to protect your data and users.

Here are the OWASP top 10 mobile vulnerabilities that you should be aware of:

1. Weak Server-Side Controls

Weak server-side controls include virtually everything that a mobile app can do poorly which doesn’t occur on the mobile device.

Then why is it in the list of OWASP top mobile vulnerabilities?

Because of the fact that most mobile apps also rely on a connection with the server, that makes them comparable to traditional client/server applications. However, that’s not the issue.

The problem is that mobile developers often do not consider traditional server-side security concerns.

In addition to this, while the majority of the security threats are fairly similar to those of web applications, an attacker’s ability to handle and gain control of a mobile device is quite different from what it is on the web.

There are various reasons that lead to server-side control issues:

• Lack of security knowledge and implementation.
• Frequent updates and rush to market.
• Using easy to work with frameworks which do not prioritize security.
• Assuming the mobile operating system takes complete responsibility for the security for mobile apps.
• Inefficient cross-platform integration and development.

How to Prevent Weak Server-Side Controls

The first and most important step to prevent weak server-side controls is to scan your mobile apps. This will help you get an overview of your mobile app’s security and identify security vulnerabilities that you may have overlooked while developing the app.

It’s recommended that you should use automated scanning tools to scan your mobile app, however, often these tools report false positives and negatives. That’s when you need human intervention. This is where it is best to hire a security expert.

Manually assessing the mobile app for security vulnerabilities will help you detect issues that may have gone undetected by automation.

In addition to this, you need to follow a secure coding development life cycle (SDLC) which includes secure coding standards and practices for developers. While it may take longer to implement secure coding practices, it helps reduce security vulnerabilities significantly.

2. Insecure Data Storage

Let’s check out the next OWASP mobile app vulnerability.

We all know storing personal or sensitive data such as credit card numbers or passwords requires a secure mechanism. Typically, developers use files and databases to store data on the client-side in mobile apps assuming that will restrict users from accessing the data.

However, recent trends show that most mobile application security breaches have been caused due to unnecessary or insecure client-data storage.

How can attackers leverage insecure data storage?

Attackers can easily root or jailbreak the mobile device and circumvent the security of mobile apps. Another way they can hack into a mobile application is if they physically attain the mobile device and connect it with a computer with freely available software.

These apps enable the attacker to see all third-party application directories which often contain stored data such as the sensitive information of users or the organization. Then an attacker can modify the legitimate mobile app to steal or delete critical data.

This could lead to several business problems such as:

• Identity or credential theft
• Fraud
• Market reputation damage
• Poor customer relationships

How to Prevent Insecure Data Storage

It is recommended to not store data in mobile apps unless absolutely necessary. For instance, never store user credentials on the phone’s file system. Prompt the user to authenticate using an API or standard web login scheme whenever they try to access the app.

When caching or storing information is necessary, consider using a standard encryption library such as CryptoKit in iOS. However, for especially sensitive apps, use white-box cryptography solutions that help prevent binary signature leakage which is commonly found in common encryption libraries.

For local storage in an android app, use the enterprise android device administration API to implement encryption of all local file-stores using “setStorageEncryption”. You should securely store encryption/decryption keys; never store in code or in configuration files.

3. Insufficient Transport Layer Protection

Insufficient transport layer protection is one of the OWASP top 10 mobile security vulnerabilities caused by mobile applications that do not protect their network traffic.

Basically, data can be exchanged between the client and the server side. If the mobile application is developed poorly, then attackers may leverage this security vulnerability and be able to view the sensitive data-in-transit.

While many developers integrate SSL/TLS certificates, they often fail to fully verify those certificates or fail to pin those certificates. This can lead to the network traffic being compromised.

How to Prevent Insufficient Transport Layer Protection

Fortunately, insufficient transport layer protection attacks are easy to prevent. Always consider that the network layer could be insecure and vulnerable to eavesdropping.

Employ TLS to transport layers that the mobile app uses to transmit session tokens or any other critical information to the web service or backend API.

Utilize certificates signed by trusted CA providers and pin those certificates that are known and trusted. Implement powerful, industry-standard cipher suites that have appropriate key lengths. Make sure you build a secure connection only after authenticating the endpoint server’s identity using trusted certificates in a keychain.

4. Unintended Data Leakage

When a developer inadvertently puts sensitive data in an insecure location on the mobile device, it could result in unintended data leakage.

Here’s why this OWASP mobile app vulnerability could be dangerous:

The insecure location could be accessible to other mobile apps running on the same device, thus leaving the mobile device vulnerable to attacks.

The code of the mobile app becomes susceptible to serious attacks since threat vectors can easily exploit these data leakage vulnerabilities. An attacker can simply add a small piece of code to access the location where the sensitive data is stored.

What are some common data leakage points?

Below are the most common leakage points that you should monitor:

• Copy/paste buffer caching
• Browser cookie objects
• URL caching
• Application backgrounding
• Keyboard press caching
• Data analytics shared with third-parties

How to Prevent Unintended Data Leakage

To prevent data leakage from caching mechanisms, set appropriate input types such as “password” types. This way, you can automatically block caching and prevent copying the content to the clipboard.

5. Poor Authorization and Authentication

Poor authorization and authentication is another major OWASP mobile app vulnerability.

Here’s how:

Poor or missing authentication schemes allow attackers to bypass authentication protocols and gain access to sensitive data in a mobile app. They do so by anonymously executing functionalities within the backend server or the mobile app.

Many mobile apps use a 4- or 6-digit PIN code for authentication. Performing a check on the client side is insecure as it would require the PIN code to be stored on the mobile device, which increases the risk of it being leaked.

Moreover, there are various mobile apps that do not expect users to be online at all times during their session. Since mobile internet connections aren’t as reliable as traditional web apps, mobile apps that require offline authentication to maintain uptime are more vulnerable to attacks.

Developers should be aware that these authentication methods can create security vulnerabilities in the mobile app. In their offline mode, mobile apps can allow users with fewer privileges to execute actions and gain unauthorized access to sensitive data.

While poor authentication and authorization are commonly prevalent in mobile apps and often go undetected, their technical and business impacts are severe.

How to Prevent Poor Authorization and Authentication

Security testers should perform attacks against the mobile app while it’s in offline mode to detect poor authentication and authorization schemes. They can force the app to bypass offline authentication protocols and try to execute functionalities that require authentication. Having a secure code review performed is also very helpful. Ideally, this should be done frequently throughout the SDLC.

Security testers can also try to execute privileged functionalities that require the authorization of a required level while the mobile app is still in the offline mode. Weak authorization will allow an adversary to successfully execute functionalities they are not authorized to execute.

Additionally, ensure that all authentication requests are performed on the server side. This will ensure that the app data is only loaded after successful authentication.

If client-side data storage is required, make sure the data is encrypted using an encryption key which is securely derived from the user’s login credentials along with a strong randomness source.

Continue read this blog at CypressDataDefense.com.

Top comments (0)