[Case Study] Jscrambler Helps Neobanks Protect JavaScript

By Júlia Rocha 5 min read

Jscrambler helps Neobanks protect JavaScript to overcome security challenges in the banking and financial services industries.

Leading Neobanks like Revolut, Nubank, and Starling Bank continue to challenge the banking industry and set new standards. However, these neobanks still face challenges, especially around application security.

Today, we explore a case study on how Jscrambler has helped Neobanks protect their JavaScript and overcome common industry challenges.

Note: We have anonymized all company and personal names.

Neobanking Model: From Innovation to Satisfaction

Neobanks defy traditional banking by betting everything on digital and delivering customer-centric payment and money-management services.

73% of 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 those 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.

This reduces product development costs and time, enabling rapid iteration and innovation by relying on third-party integrations instead of building all code in-house. However, this approach raises additional concerns about application security.

Faster Development, Larger Attack Surface

In software development, pursuing agility and speed often means widening security gaps.

Neobanks must recognize that attackers can target client-side JavaScript, despite its advantages. This may lead to intellectual property theft, code tampering, application abuse, and data exfiltration.

Without an enterprise-grade solution, this exposed JavaScript poses a business threat.

Jscrambler and Neobanks: Managing Application Security

The Challenges

Over the last few years, Neobanks, mainly from North and South America, have come to Jscrambler with significant security challenges.

With web and mobile apps built with JavaScript and, in some cases, the React Native and Ionic frameworks for cross-platform mobile development, security teams quickly realized client-side logic was 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.”

We had a high likelihood of running sensitive logic on the client side. So it became paramount to conceal this logic with the most potent and resilient technology available today.

Therefore, we had to ensure automated reverse-engineering tools would always fail to reverse the concealed code, making it infeasible for attackers to do so manually. This aligns with the security recommendations in the OWASP Mobile Application Security Verification Standard (MASVS).

Because these Neobanks’ apps handle valuable services, another key challenge was ensuring malicious actors couldn’t tamper with the code. JavaScript had to react at runtime to mitigate these attacks.

Because both web and mobile apps handle sensitive data, credentials, personally identifiable information, and financial details, another top requirement was ensuring 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 running more than one application, it was also essential to ensure JavaScript protection fit seamlessly into their CI/CD and integration tests.

The Solution

Given the challenges these Neobanks faced, they needed an on-premises solution that met the highest standards for JavaScript protection.

Polymorphic obfuscation

The first step towards securing JavaScript was Jscrambler’s polymorphic obfuscation.

With this security layer, Jscrambler concealed the source code of the Neobanks’ apps beyond recognition.

Jscrambler’s potent, resilient transformations delivered cutting-edge obfuscation.

Its inherent polymorphism ensured each new code deployment would look completely different, adding an extra layer of defense against reverse-engineering attempts.
polymorphism-obfuscation-example

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

After obfuscation, these Neobanks added an additional Jscrambler security layer to address the challenges of preventing application tampering and client-side data exfiltration: self-defense.

With this runtime protection, their apps gained a series of integrity checks that detect every debugging attempt and break the app whenever tampering occurs.

By leveraging other client-side countermeasures, such as calling a custom function, these Neobanks were able to stop malicious users.

Neobanks’ Security Engineers were well aware of the problem and the steps required to solve 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 quickly.”

The Results

5 Web and Mobile applications were secured in one week

Securing JavaScript code requires awareness of the threats that come with exposing logic on the client side. Neobanks felt this pain from the start, as their assets depended on it.

By choosing Jscrambler’s JavaScript protection technology, product teams met their main requirement: integrating a code-protection solution into their CI/CD. Now, these Neobanks deploy secure code to production, knowing each build has 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 could fulfill several OWASP recommendations, including the OWASP Mobile Top 10, which states that “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.”

For management, protecting their applications’ source code from reverse engineering and tampering meant a new competitive advantage.

With Jscrambler, Neobanks gained the upper hand in future funding rounds.

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

Conclusion

To keep their edge in the banking race, Neobanks must maintain the integrity and security of their applications.

To do this, they need enterprise-grade solutions that offer the flexibility and ease of implementation they need to keep innovating.

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