Managing Payment Page Scripts: Understanding PCI DSS Requirement 6.4.3

JavaScript skimming attacks, such as Magecart, continue to plague e-commerce businesses, targeting payment pages to steal sensitive customer data. To address this growing threat, PCI DSS v4.0 introduced Requirement 6.4.3, which focuses on managing and securing payment page scripts executed in the consumer’s browser. This requirement is also reflected in the updated SAQ A and A-EP, emphasizing the importance of protecting payment pages from client-side attacks. In this post, we’ll break down PCI DSS Requirement 6.4.3, explain its key components, and provide actionable steps to help you implement the necessary controls to secure your payment pages pages.

If you are looking for information about Requirement 11.6.1 you can find the article here.

What Does PCI DSS Requirement 6.4.3 Cover?

PCI DSS Requirement 6.4.3 applies to all payment page scripts loaded and executed in the consumer’s browser, including:

• Scripts hosted by the organization.
• Scripts loaded from third-party or fourth-party sources.

This also applies to scripts embedded in payment pages using inline frames (iframes) or other methods. However, if an organization uses a third-party service provider (TPSP) or a payment processor’s embedded payment page/form (e.g., an iframe), the TPSP or payment processor is responsible for managing scripts within the embedded payment page.

---

Key Components of PCI DSS Requirement 6.4.3

To comply with Requirement 6.4.3, organizations must implement the following measures for all payment page scripts:

1. Authorization of Scripts

A method must be implemented to confirm that each script is authorized.

This ensures that only approved scripts can run on payment pages, reducing the risk of unauthorized or malicious code execution.

How to Implement:

• Maintain a whitelist of authorized scripts.
• Use Content Security Policy (CSP) headers to restrict the sources from which scripts can be loaded.
• Regularly review and update the list of authorized scripts to reflect changes in business needs or third-party integrations.

What is CSP?
CSP is a security standard that allows website administrators to specify which content sources (e.g., scripts, and images) can be loaded on their websites. Thus, you can ensure that only authorized scripts are loaded on your payment page..

Example CSP Implementation:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://trusted-third-party.com;">

In this example, the script-src directive specifies that scripts can only be loaded from the same origin ('self') or a trusted third-party domain (https://trusted-third-party.com). Any unauthorized scripts, such as those from malicious domains, will be blocked.

---

2. Integrity Assurance

A method must be implemented to ensure the integrity of each script.

This ensures that scripts have not been tampered with or modified by malicious actors.

How to Implement:

• Use Subresource Integrity (SRI) to verify the integrity of scripts loaded from external sources. SRI allows you to specify a cryptographic hash for each script, ensuring that only the expected version is executed.
• Monitor scripts for unauthorized changes using tools that detect and alert on modifications.
• Implement file integrity monitoring (FIM) for scripts hosted on your own servers.

What is SRI?
SRI is a security feature that allows you to verify that a specific version of a script is loaded on your website. By including a cryptographic hash in the script tag, the browser can check the integrity of the script before executing it.

Example SRI Implementation:

<script src="https://example.com/script.js" integrity="sha256-5rYr5o5IgISVCGwKzZD7HPu8HLd1/W9IuAuXCXy+7K8=" crossorigin="anonymous"></script>

In this example:

• The integrity attribute contains the SHA-256 hash of the script file.
• The browser calculates the hash of the downloaded script and compares it to the hash in the integrity attribute. If they match, the script is executed. If not, the script is blocked.

Important Note: Always include the crossorigin="anonymous" attribute when using SRI. Without it, the browser may ignore the integrity check, negating the security benefits.

---

3. Maintaining a Script Inventory and Justification

An inventory of all scripts must be maintained, along with written business or technical justification for why each script is necessary. This provides visibility into the scripts running on payment pages and ensures that each script serves a legitimate purpose.

How to Implement:

• Create and maintain a detailed inventory of all scripts, including their source (e.g., self-hosted or third-party), purpose, and associated business or technical justification.
• Document the necessity of each script, such as its role in payment processing or user experience.
• Regularly review the inventory to identify and remove unnecessary or outdated scripts.

How to Identify Scripts on Your Payment Page:
You can use the following JavaScript snippet in your browser’s developer tools console to list all scripts running on a page:

(function() {
  var scripts = document.getElementsByTagName("script");
  var srcs = [];
  for (var i = 0; i < scripts.length; i++) {
    if (scripts[i].src) {
      srcs.push(scripts[i].src);
    } else {
      srcs.push("inline script");
    }
  }
  console.log(srcs);
})();

This will log all script sources to the console. Note that this may not show fourth-party scripts called by third-party scripts, so additional investigation may be required. Alternatively, browser extensions like ScriptSafe, NoScript, or uBlock Origin can provide a more user-friendly view of scripts running on a page.

Tip: Save the above JavaScript snippet as a bookmarklet to run it on your payment pages to quickly see any scripts running on your page. If you are using Firefox you can use the built-in Inspector to run this JavaScript.

---

Using Tools to Simplify Compliance

Several tools are available to help organizations manage and secure payment page scripts, including:

• SourceDefense: Offers a free solution for a single page and provides robust client-side security.
• Report URI: Provides affordable pricing.
• Other Tools: Solutions like Feroot, Reflectiz, Otto-JS, Jscrambler and Human Security also offer features to manage script security and compliance.

Most of these tools are agent less, meaning they don’t require additional JavaScript to be added to your page. However, some may require additional scripts, so evaluate each tool carefully based on your needs and budget.

---

Why PCI DSS 6.4.3 Matters

The introduction of PCI DSS Requirement 6.4.3 reflects the growing threat of client-side attacks, such as JavaScript skimming. By implementing the controls outlined in this requirement, organizations can:

• Protect sensitive payment data from theft.
• Reduce the risk of repetitional damage caused by breaches.
• Ensure compliance with PCI DSS and avoid penalties for non-compliance.

---

Conclusion

PCI DSS Requirement 6.4.3 is a critical step forward in combating JavaScript skimming attacks and securing payment pages. By authorizing scripts, ensuring their integrity, and maintaining a detailed inventory, organizations can mitigate risks and protect their customers’ sensitive data.

Whether you’re using CSP and SRI, manually maintaining a script inventory, or leveraging third-party tools, the key is to take proactive steps to secure your payment pages. Compliance with PCI DSS isn’t just about meeting standards—it’s about building trust with your customers and safeguarding their data in an increasingly hostile online environment.Take action today to secure your payment pages and stay ahead of emerging threats.

You can find an article about PCI DSS Requirement 11.6.1 here.

This new requirement along with explanation of all PCI DSS requirements check out my book Fortifying the Digital Castle.