Are Non-PCI-Compliant Scripts Putting Your Business at Risk?

In an ideal world, websites would be secure, bullet-proof, and impregnable – whatever you want to call it. But the real world is complicated.

Websites are built differently these days. They’re dynamic, not static. The business intelligence behind them has moved from web servers, owned and managed by businesses, to consumer web browsers, powered by JavaScript, distributed APIs, and microservices. 

JavaScript has become ubiquitous due to its versatility. However, its inherent security weaknesses have made it a prime target for cybercriminals. These wily and well-resourced adversaries will stop at nothing to get their hands on customer data. 

Given that payment data is particularly prized. It can be sold on or monetized via payment fraud or identity theft, so should all scripts come from a PCI-compliant source? And how should merchants verify that their service providers have taken all the necessary steps to ensure their scripts are secure?

In this article, we look at:

• How the web moved from static to dynamic pages

• Why JavaScript became ubiquitous

• Why JavaScript became a security vulnerability

• What are the new requirements to protect against and detect e-skimming?

• How do payment pages fit into the cardholder data environment?

• What are the risks of each type of payment page?

• How to mitigate the risks of JavaScript on payment pages

• How can Jscrambler help?

Why are non PCI compliant scripts putting your business at risk?

How the web moved from static to dynamic pages

In the early years of the web, pages were built entirely in HTML. They looked like the equivalent of printed pages and were static. Each click brought up a new page. Even a small change to the page meant that the entire page had to be reloaded. 

Behind the scenes, this was powered by one-to-one interactions between web browsers and web servers. Sending or retrieving data, either from within an organization or from across the web, was mediated by a web server. This made it easy to create webpages, but the user experience was stop-start.

In 1995, Sun Microsystems released Java, which enabled the dynamic exchange of data over the web. By 1999, Internet Explorer 5 began to dynamically update the news stories on the MSN homepage. This functionality was gradually adopted by nearly all browsers. And the web moved from static to dynamic pages.

Why JavaScript became ubiquitous  

JavaScript has come to power the web due to its versatility. It provides a form to collect data, enables functionality, such as tag managers or content management systems, and can be used to build entire websites. 

So much so, more than 99% of all websites use JavaScript in some form, either from code developed in-house (first party) and/or embedded from third-party vendors. This includes the payment pages of e-commerce websites. 

Jscrambler's research found that 80% of the 20 most highly trafficked US e-commerce websites had more than 130 scripts on average loaded on their payment pages, of these, 97% were third-party scripts.

Why JavaScript became a security vulnerability  

Any JavaScript running on a web page can access all data entered into form fields on that page. This makes payment pages susceptible to e-skimming attacks, also known as formjacking or Magecart attacks. 

These client-side attacks occur when cybercriminals inject malicious code onto the payment page of an e-commerce website to harvest sensitive payment card data. This includes the account number, expiration date, and 3 or 4-digit security code, which criminals can monetize. Either by using it to make unauthorized, fraudulent purchases for goods to re-sell for cash. Or by selling the data to other criminals.

Such attacks are pernicious as they can remain undetected for many months. They’re completely silent and don’t interfere with the payment process. The attack surface is also broad. Criminals can hack the website directly or attack via the supply chain, compromising either first-party or third-party JavaScript. They end up being consequences for failed compliance.

What are the new requirements to protect against and detect e-skimming?

Given the ubiquity and innate security vulnerabilities of JavaScript on payment pages, the PCI Security Standard Council (PCI SSC) published an updated version PCI Data Security Standard (PCI DSS) in March 2022. Version 4.0 of the PCI DSS contains two new requirements to protect against and detect these e-skimming attacks on payment pages.

The first requirement (6.4.3) is designed to minimize the attack surface and manage all JavaScript present in the payment page. The second requirement (11.6.1) aims to detect tampering or unauthorized changes to the payment page and generate an alert when changes are detected.

Service providers as well as merchants must prepare for PCI DSS v4 as they can impact the security of the cardholder data environment (CDE).

[LEARN MORE] Checklist PCI DSS v4.0 Requirements for Payment Pages: How to Comply

How do payment pages fit into the cardholder data environment?

PCI DSS v 4.0 defines a payment page as “a web-based user interface containing one or more form elements intended to capture account data from a consumer or submit captured account data.”

It continues that the payment page can be rendered as any one of the following:

• A single document or instance

• A document or component displayed in an inline frame (iframe) within a non-payment page

• Multiple documents or components each containing one or more form elements contained in multiple inline frames (iframe) within a non-payment page

The definition is broad to allow for the various ways in which e-commerce merchants implement payment pages. They can either store, process or transmit data on the payment page themselves. 

Or post the sensitive card data entered by their customers directly to their payment service provider (PSP). This can happen either directly on the page or via a page embedded in one or more iframes.

The security of payment pages is important because they fall within the scope of PCI DSS requirements as “system components […] that could impact the security of the cardholder data environment (CDE).” “Systems components” is further defined in PCI DDS v 4.0 to include “network devices, servers, computing devices, virtual components, cloud components, and software.”

What are the risks of each type of payment page?

There are pros and cons to each type of payment page. With an iframe, the payment form is integrated seamlessly into the merchant’s website, so customers never leave the site during the payment process. This may help reduce cart abandonment rates and increase conversion, as customers feel more secure and confident in the checkout process. 

iframes also make it easier to embed external (third-party) content on pages, reuse code across multiple pages, and sandbox content for improved security. Specifically, iframes could make it more difficult, although not impossible, to steal sensitive cardholder data. That’s because JavaScript running on the main checkout page cannot generally access data entered in an iframe payment page.

That being said, criminals have found ways to circumvent the security offered by iframe payment pages. For example, frame overlay attacks, where criminals put their own payment page on top of that of the merchant or PSP. Or fake payment pages, where they put their payment page before that of the merchant of PSP in the checkout process. 

Irrespective of what type of payment page a merchant uses, they are exposed to risks each time a service provider adds JavaScript to the CDE.

How to mitigate the risks of exposed JavaScript on payment pages

Given that any JavaScript that’s on the payment page can read and steal cardholder data many QSAs would say that every source of JavaScript loaded must be compliant with PCI DSS itself. However, that isn’t the general practice in the market. It is perhaps why the PCI SSC felt the need to add these two new requirements to PCI DSS v 4.0.

Managing the risk associated with JavaScript that executes in your customers’ browsers is already part of PCI DSS. In version 3 it certainly should have formed part of an entity’s risk assessment and, depending on an assessor’s view, potentially be included in the PCI DSS scope. 

In version 4.0, the two new requirements are currently indicated as a best practice and will become a requirement from 01 April 2025. So, when selecting a vendor and using their scripts, they must follow good security practices and be PCI-compliant as a best practice.

Jscrambler’s Client-Side Protection Platform is a holistic solution to detect and block malicious behavior on client-side web applications in real-time. It prevents leaking or scraping of sensitive data, plus protects against supply chain attacks. It is provided as a JavaScript agent that’s loaded into the customer’s browser so, of course, Jscrambler is compliant with PCI DSS v 4.0 and undergoes an annual QSA assessment to validate this.

How can Jscrambler help?

Jscrambler addresses both new PCI requirements (prevention and detection) concerning attacks on payment pages. What’s more, as the payment page is likely to include other JavaScript libraries, Jscrambler provides a smoother and easier way to manage the integrity of third-party code, compared to Content Security Policy (CSP) and Subresource Integrity (SRI).

Features include:

1. First-party code hardening and obfuscation

Obfuscation and protection of the first-party code that the Payment Service Providers supply to Merchants, further enhancing the defense against tampering with payment pages.

2. Webpage inventory 

Complete visibility of every script and network request on your website. Simplifies the identification of malicious client-side behavior and vetting of resources.

3. Third-party management

Simple onboarding and vetting of third-party scripts, with full observability of each script and a powerful rules engine that can be used to control its behavior.

4. User data management

Dashboard with details of how user data is being handled on the client-side, with insights into possible data leakage.

5. Webpage threat mitigation

Powerful and granular rules engine that blocks any script in real-time, if it exhibits malicious or prohibited behavior (e.g., form-jacking, DOM tampering, skimming, data leakage).

Jscrambler’s Client-Side Protection Platform helps companies comply with the new PCI DSS v4.0 requirements easily without breaking the functionality of payment pages.

In addition to functionality, every service provider, who provides a script on a merchant's site that could impact the security of their CDE, should also be compliant under PCI DSS 4.0. Jscrambler recently achieved attestation against PCI DSS v 4.0.