Script Security: Achieving PCI DSS v4 Compliance Before the Deadline

The Payment Card Industry Data Security Standard (PCI DSS) is a global set of security standards defined by the Payment Card Data Security Council to keep payment card data protected against evolving cybersecurity threats. Any organization that processes payment cards online, from small start-ups to large global enterprises, must adhere to each requirement outlined in PCI DSS to remain compliant and avoid penalties, including major fines. 

Latest version of PCI DSS

In March 2022, the latest version of PCI DSS was released: version 4.0. It includes several new security requirements to address changes in the threat landscape since version 3.2.1 was released in 2018. 

PCI DSS v3.2.1 will be retired on March 31, 2024, and version 4.0 becomes effective just 12 months later in 2025. This means that organizations have less than 24 months to become fully compliant with each of the changes introduced — a massive undertaking for compliance and security teams.

New script security requirements

Among the various changes in PCI DSS v4.0 are new requirements 6.4.3 and 11.6.1; these state that businesses accepting credit card payments must know what scripts are running on their online payment pages, how those scripts behave, and when those scripts change. As brands increasingly rely on the use of third-party JavaScript to improve website functionality and automate tasks, script security has become a critical concern. 

The addition of these requirements are critical in protecting against the devastating impacts of script-based attacks such as web skimming, Magecart, and formjacking. These attacks leverage script and supply chain vulnerabilities to inject malicious code into the browser and skim, as well as exfiltrate, sensitive data, including payment card details from the check-out pages of digital commerce sites. 

Many large organizations across several industries have fallen victim to these attacks, resulting in massive data breaches and financial consequences, including one of the largest GDPR fines in history.

Let’s break down exactly what each of the new script security requirements means and the lift involved for security teams to comply with them.

Requirement 6.4.3: Public-facing web applications are protected against attacks

Per v4.0, “All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:”

• “An inventory of all scripts is maintained with written justification as to why each is necessary.”

This requirement demands that organizations maintain a list of all scripts executed within the browser, as well as written reasoning about the necessity of each individual script. By justifying individual scripts, organizations are able to ensure that all scripts running are identified and used only for their intended purpose. 

Considering that a large retailer could have dozens of integrations and thousands of script iterations — including transitive dependencies executing within the browser that change frequently — maintaining an inventory of justifications per script could become an incredibly tedious task. Even with a dedicated team, the level of work required to provide justifications by individual script could take months to accomplish. 

• “A method is implemented to confirm that each script is authorized.”

This requirement demands a mechanism to confirm that every script executed on an organization’s payment page(s) is explicitly authorized. If a script observed within the browser is not justified as part of an organization’s script inventory (as mentioned above), the assumption is that it is not authorized to run. 

• “A method is implemented to assure the integrity of each script.”

This requirement demands a solution that can detect the tampering of individual scripts. Not only does an organization need visibility into each of the scripts running on their payment pages, but it also needs visibility into the behaviors of these scripts as well. If a script changes and begins to take a new unexpected action (e.g., reading data from payment form fields), organizations must be able to identify it. 

This requirement is especially important as it relates to detecting and protecting against in-browser attacks like web skimming and Magecart, in which immediate detection of script changes is critical for mitigation. 

Requirement 11.6.1: Unauthorized changes on payment pages are detected and responded to

Per v4.0, “A change-and tamper-detection mechanism is deployed as follows:”

• “To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.” 

• “The mechanism is configured to evaluate the received HTTP header and payment page.” 

• “The mechanism functions are performed as follows:

  • At least once every seven days, OR 

  • periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).”

This requirement demands a solution that can not only detect payment page tampering, but is also tamper-resistant itself. Organizations must be able to evaluate the HTTP headers as well as detect unauthorized script changes on the payment page itself. When any change is detected, alerts must be raised outlining the details of those changes — including if a payment page loses its protection. 

Organizations must routinely evaluate for script changes at least every seven days or at a defined frequency, but alerts must be “timely.” 

Announcing new Client-Side Protection & Compliance PCI DSS v4 capabilities

We introduced Akamai Client-Side Protection & Compliance back in 2020 as part of our comprehensive web application and API security portfolio. Since its inception, Page Integrity Manager has helped the world’s largest organizations gain visibility into their client-side attack surface and manage their script landscape to safeguard payment card data from in-browser threats. 

We analyze the behavior of billions of scripts on a daily basis to identify vulnerabilities and protect against even the most sophisticated script-based attacks. Now that PCI DSS v4 outlines new script security requirements, we can provide our customers with comprehensive support with the compliance process. 

We’re excited to announce the rollout of new Client-Side Protection & Compliance capabilities to help customers address each element of requirements 6.4.3 and 11.6.1 within a single tool. 

Script Inventory Management 

To address Section 6.4.3 of PCI DSS v4.0, Client-Side Protection & Compliance's new script inventory management capability provides users with an inventory of all scripts observed on protected payment pages, available directly in the Akamai Security Center.