In an ideal world, websites would be secure, bulletproof, and impregnable – whatever you want to call it. But the real world is complicated.
Websites are built these days differently. They’re dynamic, not static. The business intelligence behind them has moved from business-owned and managed web servers 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 or monetized via payment fraud or identity theft, so should all scripts come from a PCI-compliant source? How should merchants verify that their service providers have taken all necessary steps to keep their scripts secure?
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 printed pages and were static. Each click brought up a new page. Even a small change meant reloading the entire page.
Behind the scenes, web browsers and web servers communicated one-to-one. 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-and-start.
In 1995, Sun Microsystems released Java, enabling dynamic data exchange over the web. By 1999, Internet Explorer 5 began dynamically updating 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 forms to collect data, enables functionality such as tag managers and content management systems, and can 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 e-commerce payment pages.
Jscrambler’s research found that, on average, the 20 most highly trafficked US e-commerce websites had more than 130 scripts 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 into an e-commerce payment page to harvest sensitive payment card data. This includes the account number, expiration date, and 3- or 4-digit security code, which criminals can monetize. They can use it to make unauthorized purchases of goods to resell for cash. Or by selling the data to other criminals.
Such attacks are pernicious because they can go undetected for 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. These attacks are often the result of failed compliance.
What new requirements protect against and detect e-skimming?
Given the ubiquity and innate security vulnerabilities of JavaScript on payment pages, the PCI Security Standards Council (PCI SSC) published an updated version of the PCI Data Security Standard (PCI DSS) in March 2022. PCI DSS v4.0 includes 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 and merchants must prepare for PCI DSS v4, as it can affect the security of the cardholder data environment (CDE).
[LEARN MORE] Checklist PCI DSS v4 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 they can post the sensitive card data customers enter 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 integrates seamlessly into the merchant’s website, so customers never leave the site during payment. This may reduce cart abandonment and increase conversion, as customers feel more secure and confident during checkout.
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 can make it harder, though 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 place their own payment page on top of the merchant’s or PSP’s page. Or fake payment pages, where they place their payment page before the merchant’s or PSP’s in the checkout process.
Regardless of the type of payment page a merchant uses, they face risk each time a service provider adds JavaScript to the CDE.
How to mitigate the risks of exposed JavaScript on payment pages
Because JavaScript on the payment page can read and steal cardholder data, many QSAs say every source of JavaScript loaded must comply with PCI DSS. However, that isn’t the general practice in the market. That is perhaps why the PCI SSC felt the need to add these two new requirements to PCI DSS v4.0.
Managing the risk associated with JavaScript that executes in your customers’ browsers is already part of PCI DSS. In version 3, it should have been part of an entity’s risk assessment and, depending on an assessor’s view, potentially included in the PCI DSS scope.
In version 4.0, the two new requirements are currently indicated as best practice and will become requirements 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 sensitive data leaks and scraping and 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, because payment pages often include other JavaScript libraries, Jscrambler provides a smoother, easier way to manage third-party code integrity than Content Security Policy (CSP) and Subresource Integrity (SRI).
Features include:
1. First-party code hardening and obfuscation
Obfuscates and protects the first-party code that Payment Service Providers supply to Merchants, further strengthening defenses against tampering with payment pages.
2. Webpage inventory
Complete visibility of every script and network request on your website. Simplifies identifying malicious client-side behavior and vetting resources.
3. Third-party management
Simple onboarding and vetting of third-party scripts, with full observability of each script and a powerful rules engine to control its behavior.
4. User data management
A dashboard showing how user data is handled on the client side, with insights into potential 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 easily comply with the new PCI DSS v4.0 requirements without breaking payment page functionality.
In addition to functionality, any service provider that provides a script on a merchant’s site that could impact the security of their CDE should also comply with PCI DSS 4.0. Jscrambler recently achieved attestation of compliance with PCI DSS v4.0.
