(String: {%- set hs_blog_post_body -%} {%- set in_blog_post_body = true -%} <span id="hs_cos_wrapper_post_body" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_rich_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="rich_text"> <div class="blog-post__lead h2"> <p style="font-weight: bold;"><a href="/blog/digital-transformation-strategy" rel="noopener" target="_blank">Digital Transformation</a> is in full swing in the banking sector, and it’s brought along a number of crucial advantages to financial institutions.</p> </div></span>)

10 Security Flaws in Mobile Apps Banks Should Avoid at All Costs

Photo of Szymon Nitecki

Szymon Nitecki

Updated Jul 21, 2023 • 17 min read
10 Security Flaws in Mobile Apps Banks Should Avoid at All Costs

Digital Transformation is in full swing in the banking sector, and it’s brought along a number of crucial advantages to financial institutions.

But mobile banking – possibly the most important innovation from users’ perspective – comes with a number of risks. In this article, we will look at why security is such a complex issue for banking, and we’ll analyse ten security flaws that no mobile banking app should have.

What is Digital Transformation in banking

Digital Transformation solutions utilise cutting-edge technologies, including cloud computing and accessible mobile apps, to solve business problems by bringing products and services closer to users.

According to Business Insider’s US digital banking report, 89% of respondents use mobile banking to some extent, while 70% of them depend on it as the primary means of accessing their accounts.

Banks can benefit from this trend tremendously – provided that they define their strategies based on consumer behaviour. At the end of the second decade of the 21st century, people are used to always having their smartphones on them, and they want access to their money wherever they are.

The fear and distrust towards mobile banking has gone.

It’s time to leverage this change in attitude. Take a look at these two incentives to get you started:

  • In-app engagement strategies work better than traditional solutions, such as push notifications.
  • Mobile apps have the potential to deliver much better user experience than opening a bank’s website on a mobile device.

The difference between mobile banking app development and other industries

The banking sector is unique in a number of ways. Stringent security regulations for banks mean that the development process needs to be adapted to fit their security strategies. Appropriate resources should be allocated to applying good security rules to apps, at the expense of longer development time. Particularly, banking apps should go through a rigorous quality assurance process, passing every kind of test, to protect users’ interests.

Banking vs. fintech

In many ways, fintech businesses – like Revolut – have it easier.

They are often mobile-first, offering the expected suite of mobile features, and bringing Digital Transformation into the sector, thus forcing financial institutions to adapt. Fintech innovators, therefore, have a number of advantages:

  • Startups, by nature, are generally more agile and have an easier time trying out new features, whereas banks need to adhere to their own legacy of rules and regulations, and often apply long decision-making processes when adding new features or adapting to changes on the market.
  • The infrastructure of fintech apps is often tailored to work in the mobile environment, while banks need to wrangle an existing set of solutions.

As such, banks often stand before a much more complex challenge when introducing their mobile solutions. However, they have the advantage of their established position and existing customer base when launching a new mobile product.

The issue of mobile app security in banking

Why is it so important to provide the highest level of security in banking apps? To find the answer, let’s deconstruct the question first.

Data security is a complex issue due to three major aspects:

  • Software security measures,
  • Internal business processes,
  • User behaviour.

When one element fails, the others can’t always compensate. Even the most effective, well-implemented security tools won’t stop people from making mistakes.

The conclusion is bleak: your or your users’ data can never be fully secure. However, we can significantly reduce the likelihood that a mobile banking security breach will occur.

What can happen when customers’ data is compromised

There is no universal scenario for a bank security breach, as much depends on what data is leaked. For the most part, however, the consequences are dire.

  • Leaked card data can result in customers’ money being stolen.
  • Personal data can be used to reach customers with false information, leading to extortion and phishing.
  • Data breaches in bank software, even insignificant ones, can reduce customers’ trust.

Customers, especially those who suffer direct losses, may issue complaints and seek compensation, further damaging the bank’s reputation and, if the event occurs on a larger scale, causing significant losses.

Here’s an example. N26 is a European mobile banking startup. What we’re going to describe are issues that have already been fixed – N26 took responsibility for the situation. Due to lax security rules below industry standards, N26 exposed their customers data and made it possible for third parties to:

  • Manipulate transactions,
  • Take over accounts,
  • Transfer money from accounts with no funds.

Luckily, the security flaw responsible for this vulnerability was found before it could be exploited, according to N26’s statement.

The worst security flaws in banking

To provide an unbiased view of an issue so critical to the industry, we focus on flaws listed in the OWASP mobile vulnerabilities report. OWASP (Open Web Application Security Project) is an open community that creates software security guidelines and makes them available to everyone.

1. Improper use of the mobile platform

iOS and Android offer their own unique security features, such as TouchID or permissions systems. Failing to use them can be a big mistake. Each platform offers guidelines for building secure applications, and sticking to them can help you avoid many threats.

The risk: Users’ sensitive data can be corrupted through improper implementation of platform features.

The strategy: To avoid problems, implement platform-specific best security practices for the mobile interface and server-side operations. You can find them in the documentation for Android and iOS.

2. Insecure data storage

Every app uses data, and thus every app needs some data storage. For sensitive information, the storage solutions used need to be very secure (especially internal storage) – it’s the first step of successful data leak prevention.

The risk: Unprotected confidential data can be accessed and used for various illegal activities, such as stealing money from a victim’s accounts.

The strategy: Use proper, secure algorithms and and save sensitive data in internal storage with proper encryption.

3. Insecure communication

Mobile applications communicate with external data sources, such as servers, bluetooth devices, NFC, etc. This communication cannot be avoided, as apps’ core functionality often depends on it. Without adequate protective measures, however, it can result in data leaks.

The risk: There are tools and techniques for externally accessing the communication traffic of a device – such a breach may lead to fraud or identity theft.

The strategy: All communication should be encrypted using SSL, along with other appropriate communication security tools like strong authentication or good encryption algorithms.

4. Insecure authentication

Modern apps, and banking apps in particular, provide users with many authentication methods, such as user ID and strong passwords, PINs, fingerprint scanning, etc. Strong authentication allows users to manage assets within the app securely.

The risk: Without proper security measures, authentication can be bypassed by malware, resulting in unauthorised access to sensitive data.

The strategy: As local authentication is more vulnerable, apps should include server-side authentication options, if possible. Additionally, no app should store the user’s password on the device.

5. Insufficient cryptography

Cryptography uses algorithms to transform raw data into strongly encrypted, secure packages. Encrypted data cannot be read as-is, and breaking the encryption usually requires too much time and processing power for any potential attacker to succeed. Stolen encrypted data is therefore useless to them. However, some algorithms are easier to break than others, and as such they shouldn’t be used.

The risk: Weak encryption or no cryptography-based security measures expose users’ sensitive data, which can then be used for further attacks.

The strategy: Use algorithms and standards that have been thoroughly tested and accepted by the community. It’s often best to avoid storing any data on a mobile device, making it only accessible from a server.

6. Insecure authorisation

The difference between authentication (which we’ve already mentioned) and authorisation is subtle. Authentication is a method for detecting individuals, allowing the app to know who is logged in. Authorisation determines which parts of the application are accessible to a given user, based on their role (such as administrator or end user). Through well-architectured authorisation, you can make sure that each user will receive just the data they have been granted access to.

The risk: Insecure authorisation may allow users to access data that is restricted to another role. An attacker can exploit this vulnerability and gain access to sensitive information.

The strategy: Avoid relying on roles and permissions enforced on the mobile device. Instead, each role within the app should be based only on server data.

7. Poor code quality

Measuring code quality is like inspecting each block in a Lego construction. The blocks include pattern usage, test coverage, consistent coding style, proper layering, etc. If you find that your app’s code is lacking in one of these areas, it should be a cause for concern. Poor code quality makes it very difficult to maintain an application over time. Any change in the code, such as a new feature, may introduce vulnerabilities.

The risk: Attackers can use code analysis tools to steal sensitive information.

The strategy: Use consistent coding patterns following mobile app security best practices. Additionally, keep documentation of your code to help new developers on the team understand and comply with those coding patterns.

8. Code tampering

It is possible to change some parts of your app’s binary code and create copies of them. This might allow an attacker to tamper with API calls and execute malicious code. Typically, attackers distribute a malicious version of an app through phishing attachments.

The risk: An attacker may intercept communication and steal data, or gain unauthorised access to parts of the app (e.g. stored user data).

The strategy: Technically, all mobile code is vulnerable to code tampering. Mobile code runs within an environment (a mobile platform) that is not under the control of the code’s creators. Therefore, every mobile app must be able to detect at runtime that its code has been tampered with (through additions or changes), based on what it knows about its integrity during compilation.

9. Reverse engineering

Reverse engineering is the process of accessing an app’s source code from a compiled file and studying it to learn the business logic of the application. It’s even possible to use reverse engineering to check what security tools have been implemented.

The risk: Reverse engineering may reveal backend authentication secrets. It is often the first step of an attack. Reverse engineering may give an attacker useful information on an application’s logic and security measures.

The strategy: Use code obfuscation tools, making it more difficult to determine logical connections between parts of your code.

10. Extraneous functionality

Developers often create backdoors to access hidden functionalities, such as additional logs displays, or shortcuts to certain parts of the app. Though it makes development work easier, such hidden functionalities that are still present in a live app may expose sensitive data and should be avoided at any cost.

The risk: It depends on the hidden functionality. Examples include users accessing restricted features and data leaks.

The strategy: Perform a security exam for your app to make sure that all the unnecessary code has been removed from the production version.

Why it’s worth avoiding security flaws

USAA’s (United Services Automobile Association) app is one of the best mobile banking apps. It implements facial recognition through secure algorithms.

Its security features range from standard (fingerprint scanning) to very rare (voice recognition). All this to protect access to users’ bank accounts. Providing customers with this much security not only protects the company from complaints or lawsuits, but also builds trust and bolsters the image of an organisation that takes the safety of their customers seriously.

According to the McAfee Mobile Threat Report from 2018, the creation of malware is an extremely profitable endeavour, a prevalent banking Trojan could potentially bring in revenue of $1 million–$2 million.

It could create revenues for malware authors touching in the billion-dollar range by 2020. This type of criminal activity is becoming more widespread as people warm up to engaging with financial institutions online and through their mobile devices. Investing in effective security measures is now less a choice – it’s simply a necessity.

Mobile banking security tips

  1. Choose a development company that has experience in working with a high-security mindset.
  2. Keep in mind that any security flaw can expose your customers’ data, which can lead to losses for both sides, as well as complaints, lawsuits, and loss of trust. Prioritise security.

Remember that even small mobile banking security issues, without much impact on the business or users (e.g. leaked but encrypted and therefore inaccessible data), may tarnish the trust customers vest in your company.

Photo of Szymon Nitecki

More posts by this author

Szymon Nitecki

Szymon is studying at Cracow University of Economics. He started to improve his programming skills...
Developing and refining a payments app design  Read more about the successful cooperation with Careem  Check the case study

We're Netguru!

At Netguru we specialize in designing, building, shipping and scaling beautiful, usable products with blazing-fast efficiency
Let's talk business!

Trusted by: