Checklist PCI DSS v4.0 Requirements for Payment Pages: How to Comply

Explore and use the checklist PCI DSS v4.0 Requirements for Payment Pages. PCI DSS v4.0, published in March 2022, contains new provisions to protect against and detect e-skimming attacks. Sometimes also known as form-jacking or Magecart attacks, these client-side attacks occur when cybercriminals inject malicious code onto the payment pages of e-commerce websites to harvest sensitive payment card data.

The new requirements are currently best practices yet become mandates from 01 April 2025. This seems like a long while in the future, but all businesses that accept payment cards should keep their security arrangements under constant review. That’s especially true given known JavaScript vulnerabilities.

In this article, we explain the what, who, where, when, and why of the new requirements. Then, we come on to how e-commerce businesses can comply.

• What are the new requirements for payment pages under PCI DSS v4.0?

• Who must comply with the new requirements under PCI DSS v4.0?

• Where do the new requirements under PCI DSS v4.0 apply?

• When do the new requirements under PCI DSS v4.0 come into effect?

• Why comply with the new requirements under PCI DSS v4.0?

• How do e-commerce businesses comply with the new requirements under PCI DSS v4.0?

What are the new requirements for payment pages under PCI DSS v4.0?

The first requirement (6.4.3) is designed to minimize the attack surface and manage all JavaScript present on 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.

Who must comply with the new requirements under PCI DSS v4.0?

PCI DSS is intended for all entities that store, process, or transmit cardholder data and/or sensitive authentication data. 

Examples of cardholder data include:

• Primary account numbers (PANs),

• Cardholder names

• Expiration dates

• Service codes

Examples of sensitive authentication data include:

• Full track data on the magnetic stripe of a payment card or equivalent on a chip

• Card verification codes

• PINs

Typically, those involved in processing payment card data are merchants, processors, card issuers, card acquirers, and other service providers.

Where do the new requirements under PCI DSS v4.0 apply?

The new requirements (6.4.3 and 11.6.1) apply to online payment pages. So, that’s e-commerce sales, which may be conducted via a desktop, laptop, or mobile device, or completed on a website or in-app.

When do the new requirements under PCI DSS v4.0 come into effect?

The new requirements were published in March 2022 as part of version 4.0 of the PCI DSS. They remain a best practice until 31 March 2025 and become mandatory from 01 April 2025. 

The long lead times for compliance are typical for PCI DSS. However, leading e-commerce businesses have already begun to certify their compliance against the new requirements.

Why comply with the new requirements under PCI DSS v4.0?

Simply put: card data security is for everyone. Protecting customer data protects your business from brand and reputational damage and financial loss.

Whether a business is large or small. Whether it trades in shops, on the internet, on the telephone, or via mail order. Whether it accepts a few card payments every month or hundreds. This is customer card data. 

Customers are not going to thank a business or continue to reward it with their custom and loyalty if it loses their data. Or handles it in such a way that someone else can steal or hack it. 

The fully loaded costs to a business of a data breach are far bigger than just a fine. These include the direct costs of lost revenue, incident response, fines, and breach notification. Additionally, there are the indirect costs of loss of brand value, reputation, and trust. Finally, the opportunity costs of lost productivity and commercial contracts.

How do e-commerce businesses comply with the new requirements under PCI DSS v4.0?

It may seem like a long time until April 2025, but organizations should start their planning today. 

To meet the requirements, organizations will need to select technical controls and adopt new management processes for how JavaScript is deployed. Depending on the size and complexity of the organization, these may not be simple tasks. 

Here are some suggestions for assessing the current status of your organization and how to move toward compliance with the new PCI DSS v4.0 requirements.

1. Assess the JavaScript that’s currently on payment pages

The PCI DSS requirements only apply to JavaScript on payment pages. So, on the basis that you cannot manage risks you’re not aware of, the first task is to assess what JavaScript is currently on your payment page and why it is there. 

The type of information you should collect for each JavaScript you find is:

• Name of the script and URL

• First or third party

• The purpose of the script: What’s the script for?

• Which team, department, or person is the owner of each script (i.e. who decided that script should be on the page)?

• Whether the script is necessary for the operation of the payment page
  
  

You could do this by looking at the page source in your browser’s developer tools. Or request a free inventory report of all the scripts present on your website from Jscrambler.

2. Understand how your organization manages JavaScript today

The new requirement 6.4.3 requires all JavaScript on the payment page to be recorded in an inventory, be explicitly approved, and have a record kept of why the script is necessary.

Before working out how you’ll meet this new requirement, understand how JavaScript is added to your website now and the business processes currently in place. The type of information you’re looking for is:

• Which teams, people, or processes can add JavaScript to the site?

• Is there a change management or approval process for this?

• Does anyone validate the integrity of the script before it is added?

• If the script is being loaded from a third party, is there any security assessment of the third party before the script is deployed?

• Is the deployment of a new script manual or automated?

• How does the process apply to scripts that change?

• Is the same JavaScript added to every page on the site, or is it possible to separate the scripts that are included in the payment page from those that are deployed everywhere else on the site?
  
  

3. Determine your new business process

One of the key decisions you’ll need to make is whether your change control process, business operations, and risk tolerance will allow you to either:

• Approve all changes to JavaScript before they happen, or

• Approve changes within a reasonable timeframe after they happen.

This will determine the workflow and the technology that you deploy.

3.1. Pre-change approval

You’ll need a change control workflow suitable for:

• Adding (and removing) a new JavaScript to the payment page

• Changes to first-party JavaScript

• Changes to third-party JavaScript
  
  

That workflow will need to:

• Define who is allowed to add scripts to the payment page and who is allowed to approve such additions

• Record why the script must be on the payment page (and ideally, this should be to the behavior of the script)

• Record the approval of the script (e.g. who, when)

• Record any integrity information about the script, such as its behaviors and how that will continue to be verified

• Update the inventory

• Approve the new or modified script to be released to the production environment

• Interface with the manual or automatic release process
  
  

This could be implemented within an existing change-control process or with something like a spreadsheet to maintain the inventory and the information specified in the requirement.

[LEARN MORE] Myth buster: 10 of the most common PCI DSS myths busted

An advantage of a strict pre-deployment approval process is that you can use protective measures such as Content Security Policy (CSP) and Subresource Integrity (SRI). They are based on knowing the hash values of approved scripts because the hash value is computed as part of the pre-deployment process.

However, there are two operational problems with the pre-approval process. 

First, the larger and more complex an organization's e-commerce platform, the more arduous the process. There’s a real danger that the process won’t be followed if it becomes a roadblock in the development and deployment processes. 

Second, if any script changes (say by a third-party provider), then the script won’t be allowed to load, so the page's functionality will be affected. In a worst-case scenario, this could break the entire site and prevent customers from checking out.

3.2. Post-change approval

In this model, it’s still important to control who in your organization can add new JavaScript to the page and who can approve the script. This is particularly important because you’re effectively defining a time window within which a script is allowed to be active on the payment page before it is approved.

The workflow needs to be triggered by an automated process that detects when:

• A new JavaScript appears on the page.

• An already-approved JavaScript change.
  
  

The automated detection must generate an alert (which has the benefit of meeting new requirement 11.6.1) and initiate the post-change approval workflow which should:

• Record why the script must be on the payment page (and ideally this should be to the behaviors in the script)

• Record the approval of the script (e.g. who, when)

• Record any integrity information about the script such as its behaviors and how that will continue to be verified

• Update the inventory
  
  

To meet the PCI DSS requirements, if a script doesn’t get approved within a specified period, then it should be blocked or removed from the payment page.

A post-approval process is appropriate for more complex environments and ones where an organization has multiple websites or instances of a site. This is especially important where the right to add JavaScript to a site is distributed throughout an organization.

This comes with some risk because unapproved changes will be live on the site for a limited time window, which, if we extrapolate from requirement 11.6.1, should be no longer than seven days. However, it allows for scripts to change without the risk of breaking the website, especially important in the case of third-party scripts.

It is not possible to use CSP and SRI in a post-change approval model because these techniques rely on a hash of a script being generated before it is deployed. 

To effectively manage third-party risk with real-time visibility and control over every script on the website, the Jscrambler solution might be a good option.

[LEARN MORE] Jscrambler to partner with PCI Security Standards Council to help secure payment data worldwide

Jscrambler Webpage Integrity solution

A tool such as Jscrambler’s Webpage Integrity would be the preferred choice because it can enforce the required workflow as soon as it detects (in real-time) a new script added to a page or a change in an already approved script.

Using Webpage Integrity also minimizes the risk associated with an unapproved script being live on the site while the approval process is being followed because Webpage Integrity can automatically block any malicious behavior, such as a script accessing the payment card fields on the payment page.

Check out more of Jscrambler's PCI DSS resources to comply with PCI DSS v4.0. You can also explore the official PCI DSS v4.0 resource hub.

Jscrambler is helping companies comply with PCI DSS v4.0

Jscrambler's free tool helps Merchants achieve compliance with requirements 6.4.3 and 11.6.1 of PCD DSS v4.0 and QSAs to validate compliance. 

The only solution developed by:

• A PCI SSC Principal Participating Organization.

• A member of the PCI SSC Board of Advisors.

• A company with more than a decade of experience protecting JavaScript.