Script Security: Achieving PCI DSS v4 Compliance Before the March 2025 Deadline

WATCH WEBINAR HERE
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.











Users can easily record written justifications for each script observed on payment pages, categorized by known and unknown vendors to Akamai, as well as first-party scripts. Akamai’s tools automate as much of the justification setting as possible via predefined justifications and rules as well, substantially reducing compliance efforts.

PCI DSS v4 Dashboard

Client-Side Protection & Compliance’s new comprehensive PCI dashboard addresses each component of requirements 6.4.3 and 11.6.1 outlined in PCI DSS v4.0.

Script Inventory (6.4.3)

Security and compliance teams can break down the number of scripts that have or do not have written justifications applied across known/unknown vendors and first-party scripts — and do so directly within the dashboard.

Script Authorization (6.4.3)

As part of the script authorization requirements, Client-Side Protection & Compliance assumes any script that does not have a justification applied within Script Inventory is unauthorized. The dashboard summarizes the number of scripts that do not have justification (i.e., are unauthorized) across known/unknown vendors and first-party scripts.

Script Integrity (6.4.3)

As part of the script integrity requirements, Client-Side Protection & Compliance raises an alert every time a script performs an anomalous or suspicious activity. The dashboard displays the total number of alerts raised (both active and historical).

Payment Pages Protection (11.6.1)

The Client-Side Protection & Compliance dashboard summarizes the number of alerts that have been triggered relating to unauthorized modification or tampering of payment pages (e.g., data exfiltration). It also summarizes any alerts that may result from solution tampering — that is, Client-Side Protection & Compliance stops analyzing scripts on a configured page — to help organizations address requirement 11.6.1.

PCI alerts

• Unprotected payment pages alert: This alert is triggered when a previously protected payment page appears to no longer be protected, suggesting solution tampering may have occurred.
• Unauthorized scripts alert: This alert details every script that is in need of justification and considered unauthorized.
• Data exfiltration alert: This alert (by severity level) provides details of any script that may have read and exfiltrated sensitive data, such as credit card information; it provides the sensitive fields accessed by the script, and the number of sessions in which this script was observed. It also provides details of the source of the script and destination of the data, reach, and impact, and recommended actions that security teams should take to respond.

Join our beta program

Achieving each of the new requirements outlined in PCI DSS v4.0 is no easy task for security teams. As organizations strive to maintain PCI DSS compliance, the significance of script security cannot be overlooked.

By employing Akamai Client-Side Protection & Compliance and our new PCI DSS v4 capabilities, organizations can streamline their compliance efforts and ensure the protection of payment card data on their websites against in-browser attacks. We invite you to join our beta program to receive early access to these powerful features and contribute to refining the solution to further meet compliance needs.


WATCH WEBINAR HERE