PCI DSS 4.0 Compliance: A Guide to Requirements 6 & 11

These requirements of PCI DSS 4.0 compliance aim to tackle client-side risks head-on, such as Magecart, formjacking, and online skimming attacks. In this blog, we’ll unpack the latest iteration of PCI 4.0, what it means for client-side security, and what you can do to ensure compliance.

Understanding PCI DSS 4.0

The Payment Card Industry Data Security Standard (PCI DSS) is a globally recognized set of security standards that ensures all companies that process, store, or transmit credit card information maintain a secure environment.

PCI DSS 4.0 is the most significant update to the standard in a decade. It expands on earlier requirements and introduces greater flexibility for implementation, with a strong emphasis on security as a continuous process.

PCI DSS was created by major credit card companies such as Visa, MasterCard, and American Express.

View the full PCI DSS 4.0 documentation here.

What’s New in PCI DSS 4.0?

Several new or revised requirements go into effect with PCI DSS 4.0 Compliance. These updates are focused on modern threats and evolving attack surfaces:

• Emphasis on risk-based approaches to security.
• New controls for multi-factor authentication.
• Strengthened focus on script and software inventory.
• Specific language and controls addressing client-side security risks — especially those originating from third-party scripts.

Requirement 6

Requirement 6 carries significant weight when it comes to client-side security, encompassing several updates and introducing entirely new criteria as well. These changes pertain to the process by which businesses identify, document, and oversee JavaScript within web browsers responsible for gathering payment data.

• Requirement 6.3.2: Identify and list all bespoke and custom software.
  • A new key requirement – 6.3.2 – states that in order for organizations to enable vulnerability and patch management, they are now required to identify and list all of their custom and bespoke software, including any third-party software that has been incorporated into the organization’s bespoke and custom software. Vulnerabilities in third-party components such as libraries and APIs, integrated into an organization’s software can leave those applications susceptible to attacks. Therefore, it is crucial to maintain awareness of the third-party components used in the software and actively monitor the availability of security patches to rectify known vulnerabilities, ultimately safeguarding the software’s security.
• Requirement 6.3.3: Protect system components from known vulnerabilities. 
  • Requirement 6.3.3 mandates safeguarding all system components from known vulnerabilities by applying relevant security patches and updates. If you’re utilizing client-side scripts sourced from third-party libraries, it’s crucial that you implement necessary fixes to avoid the exploitation of a known vulnerability.
• Requirement 6.4.1: Public-facing web applications are protected against attacks. 
  • Requirement 6.4.1 calls for all public-facing applications to address new threats and vulnerabilities on an ongoing basis and protect these applications from known attacks.
• Requirement 6.4.2: Correctly configure automated public-facing web applications.
  • Requirement 6.4.2 clarifies that there must be proper configuration of automated public-facing web applications to identify and thwart web-based attacks. This requirement also mandates that these configurations should remain active, regularly updated, and set to either block attacks or trigger alerts when potential issues arise. Any generated alerts must be promptly investigated.
• Requirement 6.4.3: Authorize customer browser scripts. 
  • Requirement 6.4.3 states that any scripts that are loaded and executed in a customer’s browser be authorized. Additionally, an inventory of scripts must be maintained with written justification as to why each script is necessary and a method must be implemented to assure the integrity of each script.

Requirement 11

Requirement 11 is a brand new section that directly applies to client-side protection. It acknowledges that threats are no longer just server-side — attackers frequently exploit scripts, supply chains, and unsecured JavaScript on the client side.

New sub-requirements include:

• Requirement 11.6.1 – Alerting mechanisms for unauthorized changes in browser-based scripts.
• Requirement 11.6.2 – Maintaining an inventory of all scripts loaded on payment pages.
• Requirement 11.6.3 – Justifying the business purpose of each script.

Together, these steps aim to prevent formjacking, cross-site scripting, and Magecart-style attacks — all common in today’s payment ecosystems.

Achieving PCI DSS 4.0 Compliance

1. Get started now.

With the update of current requirements and brand new ones too, the shift from PCI 3.2.1 to 4.0 requires plenty of time to prep and implement. Giving your team enough time to plan and execute these best practices will help ensure compliance by early 2025.

2. Content Security Policy (CSP).

Content Security Policy (CSP) serves as an additional security layer akin to an “allowlist” when a user engages with your website and web applications. For example, when a user accesses your website, their request is transmitted to the web server, which then replies with a list of all the assets to load on that page. Throughout this operation, the system executes scripts on the client side, encompassing both first- and third-party scripts, as well as images and other assets that load in the browser. By repelling these scripts, a content security policy can intercept and prevent an attack from happening.

When dealing with front-end systems housing extensive inline scripts sourced from numerous third- and fourth-party repositories, managing policies for such complexity can become an extremely challenging and risky task. This complexity increases the vulnerability to potential attacks. Especially if third-party code, plugins or enhancements are added to the web page, this may cause policies to fail. Hence, if the organization is conducting an audit for PCI DSS compliance, there is also the concern that analysts may encounter challenges in pinpointing the reasons behind policy failures.

Automated Content Security Policy (CSP) tools can help organizations in overseeing their client-side attack exposure by implementing and overseeing CSPs within their web applications. The Feroot platform offers an advanced automated CSP solution that is proficient at recognizing all first- and third-party scripts, digital assets, and their data access privileges. Subsequently, it generates suitable CSPs by analyzing the scanned data and predicting their efficacy. Businesses have the flexibility to refine their CSPs at the domain level for streamlined management, version tracking, and reporting.

3. Implement Solutions to Support PCI Compliance.

Frankly speaking, it is going to take plenty of time and resources to document and maintain inventories of bespoke and custom software in order to securely manage all the payment page scripts that are loaded and executed in a customer’s browser. Especially if you’re a mid- to large-sized company with thousands of scripts operating on the client side, you don’t want to be doing manual code reviews.

Feroot can help automate many of the new requirements found in PCI 4.0; including granular controls required to protect payment card data on the client-side.Ready to take the first step towards PCI DSS 4.0 Compliance? Schedule a demo with a client-side security expert!