Top 3 Vulnerabilities in Mobile App Pentests

5. April 2024

During their penetration tests (pentests), our security analysts at usd HeroLab repeatedly uncover vulnerabilities that pose significant risks to corporate security. They increasingly encounter the same vulnerabilities. Our blog series "Top 3 Vulnerabilities" presents them and provides tips on how to avoid them - for #moresecurity across all IT assets.

Today we look at the three most common security-critical vulnerabilities that our analysts repeatedly encounter when pentesting mobile applications (mobile apps).

Why Mobile App Pentests?

Mobile apps often store sensitive personal and business information. Protecting any such information is of the utmost importance - not only for the user, but also for the app operator. After all, if attackers gain access to the information, this can lead to financial consequences and possible damage to the company's image. By pentesting mobile apps, security vulnerabilities can be identified and rectified proactively before attackers exploit them.

Access to sensitive data

Sensitive data stored by mobile apps includes user data, session information and application data. However, in their Mobile App Pentest, our analysts often find precisely these types of information in places that are not sufficiently protected.

In the following example, a hard-coded API key required for critical functions in the remote application API could be extracted from the decompiled code:

Security tip:

We recommend restricting access to sensitive data such as API keys and not storing them hard-coded in the app code. In the case of the API, this can be done by using a suitable authentication mechanism. If required, a token for authenticating the mobile app can be requested from a server after a login, which can then be used for a certain period of time.

However, dynamic analyses show that sensitive data is often stored unsecured on devices. Although mobile operating systems shield application data from other apps through various security precautions, this can give a false sense of security. In some cases, our analysts come across the fact that, for example, a token is stored in the shared preferences at runtime of the mobile apps.

Shared preferences are a way of permanently storing simple data in Android applications. They provide key-value storage for small amounts of data such as user settings, function states, user preferences and similar. In the following example, the authentication token is now also among this data:

It is not recommended to store sensitive data in the shared preferences under Android for several reasons. Firstly, backups of the mobile app files could expose sensitive data. If a user creates a backup of the application data, this can potentially lead to the sensitive information stored in the shared preferences appearing there in plain text. Another reason is that insecure devices, such as those that have been rooted, can pose a significant security risk. By bypassing the protection mechanisms of the mobile operating system, attackers can more easily access app data, including shared preferences. This could lead to unauthorized access to sensitive information and compromise the security of the mobile app as well as the privacy of users.

Security tip:

For this reason, it is advisable to use alternative, more secure storage options such as the Android KeyStore for storing authentication tokens or cryptographic keys. On iOS, this also applies to jailbroken devices. It is therefore advisable to store sensitive data such as passwords and cryptographic keys in the iOS Keychain.

Lack of access control

In our Mobile App Pentests, we take a holistic approach that goes beyond simply testing the mobile application. Our analysts not only examine the app itself, but also all the systems connected to it. This includes aspects such as missing access controls, where there may be vulnerabilities that allow an attacker to perform unauthorized actions.

An API server is often an integral part of a mobile app. An attacker will look at the individual endpoints of the API used after an in-depth analysis of the app. Sometimes access control is only performed at the mobile application level, while the API server does not fully implement or respect this separation.

In the following example, a request that the mobile app sends to the server has been slightly modified. It ensures that the API server changes the user's data accordingly. However, the server accepts and processes requests in JSON format with more attributes than the original application sends.

In this case, the JSON attribute "isAdmin" has been added.

When this modified request is sent to the server, the server not only changes the corresponding user information, but also grants the user admin rights.

With these access rights, requests could now be sent to the server that were originally only intended for administrators. Among other things, this made it possible to view and change the personal user data of other users.

Security tip:

The API server should ensure that each request comes from an authenticated user and that this user has the necessary authorizations to perform the requested actions. In this case, only authorized administrators should be able to change user information and, in particular, grant admin rights.

Security misconfiguration

Security misconfiguration in mobile applications refers to the improper configuration of security settings, permissions and controls that can lead to vulnerabilities and unauthorized access.

In the following example, a vulnerability was caused by the use of WebViews and deep links. Deep links in Android and iOS are URLs that refer to specific content or functions in an app. They allow users to go directly from a website or another app to a specific view or action in another app without having to manually open the app and navigate through the menus. Although deep links can improve the user experience, they are potentially dangerous as they can be misused by attackers to redirect users to malicious content or to exploit security vulnerabilities.

The following deep link, for example, could be sent to a user via a phishing attempt to exploit vulnerabilities in the app and gain access to user data:


The vulnerability exists because the app processes the deep link and opens its content in a WebView, i.e. an embedded browser. This allows an attacker to display a fake website in the design of the legitimate app. This makes it difficult for unknowing users to recognize the attack, as the fake website gives the impression of being part of the app.

Security Tip:

To prevent the attack described, developers should validate deep links, only accept them from trusted sources and process them securely. If the app displays web content in a WebView, it should be configured securely to prevent fake websites from being displayed in the app's design.

It is important to note that many other vulnerabilities may exist besides those mentioned. As every mobile application has different functions, new threats can also arise. A pentest can provide clarity and help you to effectively protect the data of your company, your customers and your employees.

Would you like to have your mobile app checked? Contact us, we will be happy to help you.

Also interesting:

DORA Deep Dive: Threat-Led Penetration Testing (TLPT)

DORA Deep Dive: Threat-Led Penetration Testing (TLPT)

The Digital Operational Resilience Act (DORA) will apply as of January 17, 2025. In addition to routine operational resilience testing, DORA will also make it mandatory for certain financial companies to carry out threat-led penetration testing (TLPT) every three...

Security Advisory on Gambio

Security Advisory on Gambio

The pentest professionals at usd HeroLab examined the online shop software Gambio during their pentests. The software offers merchants various functions that support the management of inventory and orders. Our professionals discovered a vulnerability in the password...