Vulnerabilities and threats of mobile bank apps

This article shows the vulnerabilities of the client and server parts of mobile banking applications related to errors in the code, shortcomings of client-server communication, as well as errors in the implementation of security mechanisms. Other common information security problems (for example, the shortcomings of software update management) are not considered. The level of vulnerability risk was assessed based on the degree of impact of the potential attack on user data and the application itself, as well as taking into account the complexity of the attack; qualitative estimates of high, medium and low risk levels were highlighted.

More features – more vulnerabilities

The most dangerous vulnerabilities are identified in Android applications and are related to the unsafe processing of deeplink links. Deep linking technology is used differently in iOS and Android versions. Android application developers are given more freedom to implement various functionality. This is the reason for more vulnerabilities compared to iOS applications. But this does not mean that iOS application developers cannot make mistakes. The security of the mobile bank primarily depends on the practice of Security Development Lifecycle (SDL).

100% client parts of mobile banks contain vulnerabilities in the application code:

  • there is no obfuscation of the code;
  • there is no protection against code implementation and “repackaging”;
  • the code contains the names of classes and methods.

The study showed that banks do not protect themselves from the threat of source code analysis that arises if it is not sufficiently protected. To exploit vulnerabilities in the code, attackers need to access it, and for this it is enough to download the application from Google Play or App Store and then decompile it.

The absence of code obfuscation allows it to analyze and find such important data as:

  • test logins and passwords;
  • encryption keys or parameters from which they are uniquely obtained;
  • salt used for hashing or encryption.

This information may be further used by attackers to obtain authentication data and access web servers. In addition, hackers can analyze the algorithm of the application and then take advantage of the shortcomings in business logic. Also, information about how the application works may be of interest to competitors to introduce new functionality into their products.

Recommendation for developers

Use code entanglement methods that make it difficult for attackers to read and analyze it. An example of confusion is the procedure for removing characters carried out during the assembly stage of the finance app development. It consists of replacing the original class and method names with random or one-letter names. You can use specialized software tools, such as ProGuard for Android or Sirius Obfuscator and SwiftShield for iOS.

67% attacks on individuals in the IV quarter of 2021 were implemented using social engineering methods

To exploit a number of vulnerabilities in the client parts of mobile banks, it is enough for an attacker to install a malicious application on the victim’s device, for example, during a phishing attack.

Recommendation for developers

When implementing deep linking, another entry point to the application appears, which can be used by an attacker. It should be borne in mind that all parameters transmitted by the deep linking mechanism come from an unreliable source and must be checked and filtered before being transferred to the appropriate source code methods.

11 out of 14 mobile banks allow you to automatically save screenshots to quickly view recently used programs.

The screenshot may contain confidential information, such as payment card details and bank account status.

Recommendation for developers

You only need to store the necessary amount of data on your mobile device. The required data should be requested from the server only while working with the application and should be deleted after shutdown. Encrypt confidential information stored on the device, but ensure secure management of encryption keys. To protect the data in screenshots, use a special background image that will overlap the mobile bank screen containing important information.

23 vulnerabilities on average, they are contained in the server part of each mobile bank

Recommendation for developers

Integrate the SDL principles into the development lifecycle, which include analyzing the security of code while writing it.


None of the mobile banking applications studied has an acceptable level of security. Banks do not protect themselves from the threats of mobile application analysis, do not pay enough attention to the protection of source code, store important data on mobile devices in an open form, make mistakes that allow you to bypass authentication and authorization mechanisms, select credentials for the application.

As before, we recommend that banks pay more attention to security issues both at the design stage of mobile applications and at the development stage. So feel free to let Stfalcon hire flutter developer. Due to the large number of shortcomings in the source code, it is worth reviewing the approaches to development at all stages of the application life cycle: there may be shortcomings or the practices of secure SDL programming may not be applied.

Back to top button