May 10, 2022

Application Security in Banking

By Jscrambler | 3 min read

Application-Security-in-Banking-1

In recent years, we have seen the technologies used for creating web products develop rapidly, and JavaScript became the predominant language of the Web. In fact, JavaScript is part of 97% of modern websites and every single Fortune 500 company is using it.

In this blog post, we are going to dive deeper into the security concerns associated with the use of JavaScript in banking applications.

Client-side JavaScript: security considerations

JavaScript is an interpreted language—meaning, client-side JavaScript requires an interpreter in the browser to read it, interpret it, and run it. This also means that anyone can use a browser debugger to easily go through the JS code and read or modify it.

With such easy access to client-side JavaScript code, it’s almost effortless for an attacker to take advantage of this security weakness and target any unprotected code. And, since virtually every company is using JavaScript to develop their apps, they must consider the underlying security risks posed to their applications—especially the ones that handle sensitive user data, such as mobile banking, e-commerce and streaming services.

The rise of mobile apps in banking

In the case of banking specifically, we have seen the industry continuously shift towards a digital-centric approach. Nowadays, you can pretty much perform any financial operation through a mobile or web app without any hassle, all while having a great user experience.

Despite all the benefits that come from this digital transformation, which has stimulated a highly competitive banking industry, there are still some security considerations to keep in mind. For instance, the emphasis on development speed often makes companies put security as an afterthought rather than a priority. And in the case of the financial industry, this is especially concerning, since there is a large volume of sensitive data put at risk.

Consequences of unprotected source code in banking applications

If left unprotected, due to the nature of data they handle, banking apps are susceptible to data leakage and fraud attempts. Attackers can leverage web supply chain attacks, relying on the lack of visibility companies have over their third-party code, to inject malicious code into their websites and tamper with transactions and personal data.

In turn, those attacks also result in a breach of compliance with regulations and standards, such as GDPR, which ends up bringing in heavy fines for organizations.

Given the high degree of exposure of sensitive data in these applications, it’s no surprise to see security standards such as PCI DSS now requiring compliant companies to keep an updated inventory of all of their website’s scripts and monitor in real-time for the addition of any malicious code such as payment card skimming code.

The state of application security in banking applications

Today, the vast majority of banking institutions have gone through a stage of digital transformation. So, have these institutions given enough attention to the client-side security of their web and mobile applications?

To answer this question, the Jscrambler research team has looked deeper into some regions around the globe to see what the state of application security in banking actually looks like. The results show some interesting patterns.

In the LatAm region, we had previously found that around 63% of banking applications don’t use any obfuscation techniques in their code. The same thing is true for Brazilian banking apps, 65% of which leave their code unprotected. This means that the vast majority of banking apps in these regions are vulnerable to various client-side attacks, as outlined in standards like ISO 27001, OWASP, and NIST.

“Program source code can be vulnerable to attack if not adequately protected and can provide an attacker with a good means to compromise systems in an often covert manner.”
ISO 27001 Standard

Now, the Jscrambler research team has delved into the UK banking industry, seeking to understand if banking apps in this region are equally lagging behind in terms of security. You can get first-hand access to these insights by watching this webinar.

Protecting banking applications, keeping user data secure

In order to adequately protect banking apps from attacks, it's crucial that organizations adopt application shielding and third-party management techniques. This includes making sure that the client-side source code is protected using a multi-layered approach (obfuscation, environment checks, and runtime protection), while also gaining full visibility of all third-party code running on the banking website, through a website inventory.

Both of these dimensions are essential to ensure secure data management practices and the mitigation of client-side threats in real-time before they even become a problem.

To learn more on the subject of application security in banking apps, please refer to the following resources:

Lastly, if you want to start securing your JavaScript code, you can try Jscrambler for free.

Author
JscramblerThe leader in client-side Web security. With Jscrambler, JavaScript applications become self-defensive and capable of detecting and blocking client-side attacks like Magecart.
View All Posts

Subscribe to our weekly newsletter

Learn more about new security threats and technologies.

I agree to receive these emails and accept the Privacy Policy.
Projeto Co-Financiado por (Mais info)