Client-side

In modern times, web apps and pages load an average of more than 30 scripts from third-parties at runtime on the user’s browser. Naturally, the potential for compromise via that user’s device has been growing exponentially.

When relying on third-party code that’s integrated into the user experience almost in real-time, it considerably opens the door for an attack to happen.

The organization that owns and operates the website that’s being viewed by the user does not have control over the code or visibility into how the code is behaving at runtime. And, considering the rise of online shopping, as more transactions are made online and more sensitive data transverses networks as a result, the greater the incentive and opportunities for client-side attacks.

Furthermore, client-side JavaScript can easily be targeted since anyone can debug the code and even modify it at runtime. This becomes problematic because companies store important business logic on the client-side, which is often unavoidable due to the absence of a back-end or the need to avoid performance losses.

Companies’ proprietary algorithms and logic end up running in an adversarial environment, which opens the door to a series of attacks, including automated abuse, piracy, intellectual property theft, and data exfiltration. And unfortunately, client-side attacks take longer to be detected.

Considering the risks of Magecart or Web Supply Chain attacks, regulators have been insisting on strict regulations to ensure that businesses protect themselves and their sensitive data.

Client-side attacks occur when a malicious actor takes advantage of security weaknesses or vulnerabilities that exist on the end-user's device, whether it is a mobile device, a browser, or any other client application.

Because there’s so much sensitive data being handled on the client side nowadays, including personally identifiable information (PII), payment data, protected health information, etc., client-side attacks are considered one of the most dangerous types of security threats.

Because data handled on the client-side must be unencrypted, this also presents attackers with a window of opportunity to access and potentially leak this data before it is encrypted and sent over the network to be stored at a secure server.

Client-side attack examples

Some of the most relevant examples of client-side attacks include Magecart web skimming attacks, where malicious actors tamper with client-side payment forms to collect credit card information and send it to their own servers, and customer hijacking, where the user is diverted to another page.

The common goal of this method is to steal valuable information from a webpage, computer, or server, especially sensitive information such as credit card numbers. Enterprises like British Airways and Ticketmaster are two of the thousands of victims.

There are available several key frameworks that provide information about client-side vulnerabilities.

OWASP

One of the most popular frameworks is OWASP, the Open Web Application Security Project. It is a non-profit entity with international recognition, acting with a focus on collaboration to strengthen software security worldwide. OWASP maintains a list of the 10 most dangerous web application security flaws, along with the most effective methods for dealing with them.

Cybersecurity Framework from NIST

The Cybersecurity Framework from the US National Institute of Standards and Technology (NIST) is also very well-known. Both of these frameworks highlight the importance of ensuring the integrity of both first- and third-party code running on the client-side of web applications.

Regulatory requirements

In addition to these guidelines, there are also regulatory requirements that mandate client-side security, especially in e-commerce environments. The most important requirement is the Payment Card Industry Data Security Standard (PCI DSS), which just issued version 4.0.

PCI DSS mandates the monitoring and maintenance of an inventory of all code on a website’s payment pages, as well as the deployment of a tamper-detection mechanism that prevents the introduction of credit card-skimming code to payment pages.

Considering the dynamic nature of the web and JavaScript itself, there are several security aspects that must be taken into consideration to address client-side vulnerabilities.

1. Real-time monitoring

One of the best ways to guarantee full visibility and control on the client-side is to implement real-time monitoring.

You need to be able to detect, at any time, if there is any unauthorized script activity on your website.

To minimize the risk and the attack surface, you want to receive alerts when that is happening, as well as, of course, be able to act immediately and block or deactivate any malicious script.

2. Get visibility into third-party scripts

Additionally, it’s also recommended that you are fully aware of all the third-party scripts that are present on your website.

This might come from marketing or analytic tools that are broadly used on most websites. For this, it’s very helpful to maintain a dynamic inventory of all the scripts present on your website, including first-party and third-party code.

It is also one of the requirements mandated by version 4.0 of PCI DSS, which mandates that e-commerce businesses maintain a full inventory of every script on their payment page.

3. Other client-side attack prevention strategies

There are also other important methods that should be considered:

• First, regularly update and patch all the software and apps associated with your website;
  
  

• Beyond that, you should use monitoring and inspection technology that alerts in case of any unauthorized script activity. This should include a detection capability, scanning for anomalies, intrusions, or unknown threats;
  
  

• Content Security Policies (CSPs) can help detect and mitigate certain types of attacks. They provide an extra layer of protection but they aren’t enough by themselves: you should also be aware of the shortcomings of CSPs, in that (a) they can be bypassed if they use static whitelists and (b) they lack granularity, relying on a binary “block or allow” approach to third-party access, which fails to address issues such as “allow this unless…”;
  
  

• Split front-end applications into smaller components, e.g. public-facing, authenticated, and admin, so as to compartmentalize them and thereby reduce potential blast radiuses;
  
  

• Store sensitive website data in a dedicated meta field and keep API keys hidden from public view;
  
  

• Use SSL certificates for all websites and keep them up-to-date;
  
  

• Exercise extreme caution in the selection and implementation of third and fourth-party scripts (i.e. those that a third-party supplier itself sources from elsewhere);
  
  

• Maintain a dynamic inventory of all website scripts, including third-party and first-party;
  
  

• Monitor in real-time for any services attempting to access and leak sensitive data on the website;
  
  

• Adopt a proactive approach to client-side security, restricting the behaviors of website scripts to prevent them from tampering with forms and/or leaking sensitive data;
  
  

• Protect first-party JavaScript from reverse engineering and tampering attempts, both statically and at runtime.

Jscrambler Code Integrity uses obfuscation techniques, code locks, and self-defensive features to completely protect JavaScript code and block attackers from debugging the code.

This is a best practice and an OWASP recommendation for Mobile Applications that Jscrambler enables for JavaScript-based applications, whether running on a mobile device, web browser, or server-side.