The new PCI DSS v4.0 Requirements: a checklist to guarantee your company’s compliance

The new PCI DSS v4.0 Requirements Checklist for Compliance has been developed from PCI DSS v4.0's new two requirements designed to protect against (requirement 6.4.3) and detect (requirement 11.6.1) e-commerce skimming attacks. These two new requirements are best practices until April 1, 2025, after which they become mandatory requirements.

PCI DSS 4.0 Contains Two New Requirements

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.

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

The PCI DSS requirements only apply to JavaScript on payment pages. The first task is to make an inventory of what JavaScript is currently on your payment page and why it is there. 

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

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
  
  

2. Understand how your organization manages JavaScript

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, it’s important to understand how JavaScript is added to your website now because you may already have some business processes 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 out 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 in a sensible window 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 that caters to:

• 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 an addition

• Record why it is necessary for the script to be on the payment page (and ideally, this should be in relation 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 will be able to 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 will be able to be computed as part of the pre-deployment process.

But 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 it won’t be followed because 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, and so the functionality of the page will be affected (in the worst case, breaking the entire site).

3.2. Post-change approval

In this model, it is 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 in 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 it is necessary for the script to be on the payment page (and ideally this should be in relation 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 time 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.

It 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 the website breaking, which will be especially important for 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.

Jscrambler Webpage Integrity solution

A tool such as Jscrambler’s Webpage Integrity would be the preferred choice because it is able to 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.
  
  

Try the PCI DSS JavaScript Compliance Tool!