[Case Study] Jscrambler Helps Neobanks Protect JavaScript

Leading Neobanks like Revolut, Nubank, Starling Bank, and many others keep challenging the banking industry and setting new standards — but all these Neobanks have their own challenges to address, specifically when it comes to application security.

In this post, we will explore a case study on how Jscrambler has helped Neobanks protect their JavaScript and overcome some common challenges in their industry.

Note: As per the request of our clients, we have anonymized all company and personal names.

Neobanks defy traditional banking by betting everything on digital and delivering customer-centric services for payments and money management. Today, 73% of all consumer interactions with banks are done digitally. While traditional banks have invested in Web and mobile platforms, Neobanks release twice as many new features and three times more app updates per year. They also run 42% faster than incumbents. As a result, user satisfaction ratings for Neobanks in the US (90%) are much higher than that of traditional banks (66%).

Neobanks’ technological flexibility comes from investing in cloud-based infrastructure and advanced web and mobile applications using modern JavaScript frameworks such as React Native. With this approach, they cut product development costs and time, paving the way for rapid iteration and innovation. This is greatly aided by relying on third-party integrations instead of having to develop every piece of code in-house. However, this approach also brings some additional concerns when it comes to application security.

In software development, pursuing agility and speed often means widening security gaps. Despite JavaScript’s numerous advantages, Neobanks must be aware that client-side JavaScript is can be targeted by attackers - leading to intellectual property theft, code tampering, application abuse, and data exfiltration. Unless protected with an enterprise-grade solution, this exposed JavaScript poses a key business threat.

The Challenges

Over the last few years, Neobanks mostly from North and South America have come to Jscrambler with significant security challenges. Having web and mobile apps built using JavaScript — with a strong incidence of the React Native and Ionic frameworks for cross-platform mobile development — development and security teams understood early-on that client-side logic would be a security liability.

"Protecting our JavaScript was a requirement from day one. Investors and management made sure that it was a priority. Today, not a single product ships without secure client-side logic - and this has been extremely effective."

There was a high likelihood of having to run sensitive logic on the client-side, and so it became paramount to guarantee that this logic would be concealed with the most potent and resilient technology available today. As so, it was mandatory to ensure that automated reverse-engineering tools would always fail to reverse the concealed code, as it would be extremely unfeasible for attackers to achieve it manually. This goes hand in hand with the security recommendations from the OWASP Mobile Application Security Verification Standard (MASVS).

As these Neobanks’ apps handle valuable services, another key challenge was guaranteeing that malicious actors wouldn’t be able to tamper with the code. JavaScript had to react in runtime to mitigate these attacks.

And since both the Web and mobile apps handle sensitive data - credentials, personally identifiable information, financial details - an additional pre-eminent requirement was guaranteeing that JavaScript couldn’t serve as a gateway for attackers to plan attacks that would steal user data.

"We’re called “challenger banks” for a reason - one of our toughest challenges is still gaining customer trust. When handling their data, we can’t just meet the minimum requirements - we must excel at it and keep data safe at all costs."

With each Neobank possessing more than one application, it was also essential to guarantee that JavaScript protection would fit seamlessly into their CI/CD and integration tests.

The Solution

Given the challenges these Neobanks were facing, they had to meet the highest standards for JavaScript protection with an on-premise solution.

The first step towards securing JavaScript was Jscrambler’s polymorphic obfuscation. With this critical security layer, all of the source code of the Neobanks’ apps was concealed beyond possible recognition. Here, Jscrambler’s set of the most potent and resilient transformations was key to guarantee cutting-edge obfuscation. Its inherent polymorphism ensured that each new code deployment would be completely different — making it an extra line of defense against reverse engineering attempts.

"The concealed code looks like absolute non-sense and passed all of our tests. Being able to pick from dozens of well-documented transformations and fine-tune each one was very important."

Following obfuscation, these Neobanks leveraged an additional Jscrambler security layer to meet the challenges of preventing application tampering and client-side data exfiltration: self-defending. With this runtime protection, their apps gained a series of integrity checks that detect every debugging attempt and also break the app whenever tampering occurs. Taking advantage of other client-side countermeasures, such as calling a custom function, has enabled these Neobanks to further stop malicious users.

Neobanks’ Security Engineers were well aware of the problem and the required steps for solving it. After the initial setup of their Jscrambler instance, it took on average 1 week and 2 meetings with Jscrambler’s Engineers to integrate Jscrambler seamlessly into their CI/CD pipeline. From there, Jscrambler became an automated part of their application build process.

"The Jscrambler team has extensive knowledge of JavaScript. Communication with our engineering teams was excellent and all issues were solved very fast."

The Results

5 Web and Mobile Applications secured in 1 week

Securing JavaScript code, first and foremost, requires awareness of the threats caused by having important logic exposed on the client-side. Neobanks clearly have this pain from the very onset of the business, as their main assets depend upon it.

By opting for Jscrambler’s proven JavaScript protection technology, product teams met their main requirement of integrating a code protection solution seamlessly into their CI/CD. Now, these Neobanks deploy secure code to production knowing that each build has a fresh set of the most potent and resilient JavaScript protection available today.

"Today, not a single product ships without secure client-side logic - and this has been extremely effective."

In parallel, security teams were able to fulfill several security recommendations by OWASP, namely the OWASP Mobile Top 10, which states “in order to prevent effective reverse engineering, you must use an obfuscation tool” and “The app must be able to react appropriately at runtime to a code integrity violation”.

To management, ensuring that their applications’ source code was protected against reverse engineering and tampering ultimately meant a new competitive advantage. Keen investors are aware of the liability posed by exposed JavaScript in Neobanking; with Jscrambler, Neobanks gained the upper hand in future funding rounds.

In an industry where numbers are everything, for these Neobanks, Jscrambler’s outcome couldn’t be rounder: 0 integration issues, 0 successful attacks to JavaScript code.

Conclusion

To maintain their edge in the banking race, Neobanks need to maintain the integrity and security of their applications. To do it, they need powerful enterprise-grade solutions that offer them the flexibility and ease of implementation they need to continue innovating at a fast pace.

If you also want to secure your JavaScript source code against theft, reverse-engineering and much more, you can try our solution for free.