PCI DSS 4.0.1 Released: Changes to Requirements 6.4.3 and 11.6.1

PCI DSS 4.0.1 was released on June 11th, 2024.

It’s a limited revision that aims to correct small typographical errors and make clarifications. However, sometimes such clarifications translate into more than significant changes to a requirement.

In version 4.0.1, some changes affect both requirements 6.4.3 and 11.6.1.

Changes brought by PCI DSS v4.0.1

Requirement 6.4.3

What’s necessary?

In 4.0, guidance was given that necessary in the context of a script in the payment page meant “needed for the functionality of the payment page to accept a payment transaction”. In 4.0.1 this has changed to “a business or technical justification as to why each is necessary” as part of the Defined Approach Requirement. Moving this from the Guidance to the requirement itself makes it normative (i.e. what you need to do to fulfill the requirement, rather than just informative).

Jscrambler’s Recommendation

This is a significant weakening of the requirement, but it reflects that the business often needs scripts on the payment page that are not necessary for making a payment. Our advice is that you should aim to reduce the number of scripts on the page because that reduces the attack surface and use Jscrambler’s Webpage Integrity (WPI) to secure and manage the scripts on the page.

When to authorize?

It’s impossible to authorize changes to third-party scripts before they are made. None of the third-party script providers are going to include you in their change control process. And even internally, someone using a tag manager will add a script to your payment page without anyone else’s knowledge.

The practicalities of managing third-party scripts have now been reflected in the guidance with the following added.

“Where it is impractical for such 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.”

Jscrambler’s Recommendation

WPI is a great solution for managing new and changed third-party scripts. You’ll get a real-time alert as soon as a new or changed script appears, and then you can kick off the authorization process.

Be Present or Execute?

There’s been a very subtle and welcome change to the customized approach objective.

In 4.0 it said: “Unauthorized code cannot be present in the payment page as it is rendered in the consumer’s browser.”

And now in 4.0.1, it says: “Unauthorized code cannot be executed in the payment page as it is rendered in the consumer’s browser.”

Jscrambler’s Recommendation

This is a sensible change. It is often impossible to stop malicious JavaScript loading (i.e. being present) but tools like Webpage Integrity can block malicious behaviors in real time. 

Scripts in pages that host PSP’s payment pages in iFrames?

Most merchants now don’t create the payment form themselves, but they load a Payment Processor/PSP’s form into an iFrame. This means they don’t store, process or transmit cardholder data but, because they control the loading of the iframe, they can affect the security of the payment card data.

The first clarification in the Applicability Notes aims to reduce the risk of attacks against the iframe such as overlay or hijacking attacks:

“This requirement also applies to scripts in the entity’s webpage(s) that includes a TPSP’s/ payment processor’s embedded payment page/form (for example, one or more inline frames or iframes).”

The extension of the requirement to the page hosting the PSP’s iframe was previously included in SAQ A.

Jscrambler’s Recommendation

 Moving this applicability from SAQ A into the standard makes it clear and closes a loophole that the requirement did not apply to SAQ-ineligible merchants. 

Who needs to comply?

There are two further clarifications in the Applicability Notes, which we understand address questions that have been frequently asked of the PCI SSC. These are:

This requirement does not apply to an entity for scripts in a TPSP’s/payment processor’s embedded payment page/form (for example, one or more iframes), where the entity includes a TPSP’s/payment processor’s payment page/form on its webpage.

And

Scripts in the TPSP’s/payment processor’s embedded payment page/form are the responsibility of the TPSP/payment processor to manage in accordance with this requirement.

Again, it covers the common architecture where a merchant’s web page contains the payment page from a PSP in an iFrame. And, although wordy, these two Applicability Notes really just say that:

• The merchant is only responsible for scripts loaded into the page that hosts the iframe (aka the Parent Page) and not for any scripts that are loaded in the iframe.

• The Payment Processor / PSP is responsible for all scripts loaded in the iFrame

Jscrambler’s Recommendation

Practically the clarification about the responsibility for the contents of an iframe is useful, although this was always the intention of the requirement.

However, the clarification would have been better had it made it clear this was only the case when the PSP’s payment page was loaded in cross-origin origin iframe. Jscrambler has seen some instances where the PSP’s iframe was created in the same origin as the merchant’s parent page, which means the merchant should have responsibility for scripts loaded in the parent page and the payment page in the iframe.

The Merchants’ and PSP’s responsibility

The final change in requirement 6.4.3 can be found in the Good Practice section of the Guidance. 

“Where an entity includes a TPSP’s/payment processor’s embedded payment page/form on its webpage, the entity should expect the TPSP/payment processor to provide evidence that the TPSP/payment processor is meeting this requirement, in accordance with the TPSP’s/payment processor’s PCI DSS assessment and Requirement 12.9.”

This advice complements the new clarification of the responsibilities of merchants and PSPs and makes it clear to the merchant that although they are not responsible for the scripts loaded into a TPSP or a PSP’s iframe, they should check that the PSPs are aware of its requirements.

Jscrambler’s Recommendation

This is good advice in respect of a Payment Processor or PSP, but it doesn’t make any security sense for scripts loaded into a different cross-origin iframe from any non-payment related Third Party Service Provider.

Requirement 11.6.1

Just security-affecting changes

Two extremely helpful clarifications have been added to the Defined Approach Requirement. They reflect the initial intent of the requirement and correct what can only be described as sloppy drafting in 4.0.

The original requirement was to detect unauthorized changes to “the HTTP headers and the contents of payment pages as received by the consumer browser.”

And in 4.0.1 this has been changed to “the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.”

Clarifying that only changes that can affect the security of cardholder data are the ones that need to be monitored.

Jscrambler’s Recommendation

The change reflects how most entities were interpreting the requirements.

Weekly or every seven days?

In version 4.0, the SSC made a real attempt to harmonize the language used to describe time periods. Requirement 11.6.1 didn’t get the message. It’s now fixed to say “weekly” instead of “at least once every seven days”.

Jscrambler’s Observation

Different words. Same meaning.

Who needs to comply and who is responsible?

The same additions to the Applicability Notes that were added to requirement  6.4.3 have also been added to 11.6.1.

Jscrambler’s Observation

As with 6.4.3, making this requirement apply to the Parent Page of an iframe that contains a payment page will protect against the growing number of attacks against iframes. It makes no practical difference as this provision had already been included in SAQ A.

Improved Guidance

There are some minor clarifications in the Guidance that:

• Explain why checking the HTTP headers is useful in detecting a skimming attack 

• Mirror the Good Practice in 6.4.3 that the Payment Processor should provide evidence that they are meeting this requirement for a payment page in an iframe

• Detail that the list of examples given is not the only way of potentially meeting the requirement, and also that it’s fine to use a combination of approaches or tools.

Jscrambler’s Recommendation

Highlighting that a combination of approaches can be used to meet the requirement is helpful, although Jscrambler’s Webpage Integrity is sufficient to meet 6.4.3 and 11.6.1 on its own.