While many of us have been hard at work wrapping our heads (and organizations) around PCI DSS 4.0 readiness, the PCI Security Standards Council has been reviewing the community’s feedback and has just released PCI DSS 4.0.1.

Read on for a summary of the changes to the browser script requirements in PCI DSS 4.0.1 (here’s a quick overview of the v4 requirements for reference) and register for our webinar, The 411 on PCI DSS 4.0.1, to learn more about the changes.

Requirements 6.4.3 and 11.6.1: Notable Clarifications

Though no requirements have been added or removed, there were a few significant clarifications to the browser script requirements, 6.4.3 and 11.6.1.

Applicability (6.4.3 and 11.6.1)

This update goes a long way toward clarifying to whom 6.4.3 and 11.6.1 apply. Previously, many merchants embedding payment pages/forms from third-party service providers (TPSPs) believed they had been de-scoped. 4.0.1 explicitly addresses that misconception by moving the applicability notes from SAQ A into the main PCI DSS document under both requirements 6.4.3 and 11.6.1.

This change explicitly clarifies a question we have previously explored: How does script compliance ownership split between the merchant and the TPSP? The answer could be summarized as:

• The merchant owns scripts and headers outside of the embedded TPSP’s iframe
• The TPSP owns those on the inside

However, some ambiguity remains for merchants who redirect to a TPSP. The new applicability wording does not explicitly state whether such merchant pages are in or out of scope. Pending an SAQ A update, we are left with SAQ A r2's existing applicability notes to understand the absolute minimum that smaller merchants are expected to follow. It clarifies that 11.6.1 is out of scope, but doesn't quite clarify 6.4.3. 

From Eligibility Criteria in SAQ A r2, July 2023

While SAQ A r2 defines the absolute minimum for smaller sites, the bar might be higher for larger merchants. From a "security beyond compliance" perspective, scripts on the redirecting server impact how the account data is transmitted, and should therefore be scoped and secured.

Art Cooper, Principal Security Consultant at TrustedSec, emphasizes the difference between links and redirects when scoping applicability for organizations that use TPSPs. He shared this rule of thumb on a panel with the PCI Dream Team:

• iFrames and URL redirects to anything payment-related - IN SCOPE
• Hard links that point directly to a payment page - IN SCOPE
• Hard links to a landing page or anything else not payment-related - NOT IN SCOPE

Authorization (6.4.3)

Under “Purpose,” guidance was added to address situations where it is impractical for scripts to be authorized before a script is changed or added to the page. Version 4.0.1 states that “where it is impractical for authorization to occur before a script is changed or a new script is added to the page, the authorization should be confirmed as soon as possible after a change is made.” 

This change is an important acknowledgment that browser scripts are nearly impossible to evaluate and control before they hit production websites without hamstringing online businesses. 

In balancing business value and risk, HUMAN’s PCI DSS Compliance solution provides deep insight into risky script changes and responds proactively with in-browser mitigation to protect cardholder data. Using a sensor embedded in merchants' websites, the solution runs in real consumer browsers to auto-discover and inventory all client-side scripts, assure script integrity, and confirm that all payment page scripts are indeed authorized.

Justification (6.4.3)

Version 4.0.1 has removed definitions that explain what “necessary” means for this requirement. Previously, it had been stated that justification was necessary for all scripts “needed for the functionality of the payment page to accept a payment transaction.”

This change recognizes that modern online businesses cannot operate without additional scripts, which may not meet the previous stringent wording. Having said that, we believe the spirit and intent of “justification” is unchanged. Simply put, if the script doesn’t absolutely need to be there, remove it. 

And a shameless product plug: if the script is necessary, HUMAN’s PCI DSS Compliance solution will help you confirm the behavior of any changed scripts in real-time and can proactively mitigate bad behavior before it occurs, without interrupting the value the script provides to business.

HTTP Headers (11.6.1)

In version 4.0, requirement 11.6.1 stated that “a change- and tamper-detection mechanism must be deployed to alert of the unauthorized modification of HTTP headers and contents of payment pages as received by the consumer browser. Version 4.0.1 clarifies that this requirement applies to “security-impacting HTTP headers and the script contents of payment pages.”

This clarification is huge and extremely sensible. The previous version potentially implied monitoring all HTTP headers and all contents of payment pages. The problem is the seemingly infinite http headers and contents of payment pages that change constantly, often simply as a result of routine website builds. The vast majority of these headers and "content" are completely harmless. The deluge of “false alarms” would quickly drown out any potentially material security-impacting events. 

The clarification to focus on "security-impacting HTTP headers" and "script contents" aligns well with HUMAN’s practicality-driven approach to 11.6.1: monitor every single script, but only monitor HTTP headers that matter.

How to Achieve PCI DSS 4 Compliance

The deadline for PCI DSS 4 compliance is nine months away, so organizations have their work cut out for them. HUMAN streamlines compliance with requirements 6.4.3 and 11.6.1, without disrupting scripts’ business value.

If you are a merchant, TPSP, or QSA looking for the easiest way to secure payment pages and comply with these new browser script requirements, visit our site and/or contact us to learn how HUMAN can help.

Disclaimer: This post includes our opinion as client-side security experts, including within the context of PCI DSS. This post neither assumes nor replaces entities’ responsibility to interpret and scope PCI DSS. Please do your own research and consult a Qualified Security Assessor (QSA).