The PCI SSC has published a new information supplement (Information Supplement) oriented to security on payment pages and prevention of e-skimming attacks as a guide for the implementation of PCI DSS v4.0 controls 6.4.3 and 11.6.1.

In March 2025 the PCI SSC published the Document Information Supplement: Payment Page Security and Preventing E-Skimming – Guidance for PCI DSS Requirements 6.4.3 and 11.6.1 It explains in more detail the controls for protection against e-skimming attacks. This document is the result of the work of the E-Commerce task forces (E-Commerce Guidance Task Force) and small and medium-sized businesses (Small Merchant Business Task Force), with the support of other equipment such as the Global Executive Assessor Roundtable (GEAR). The need to have this information supplement arose from the number of doubts generated after the inclusion of controls 6.4.3 and 11.6.1 in the version of PCI DSS v4.0, whose entry into force will be on April 1, 2025.

Content and organization of this information supplement

As we had already advanced in PCI Hispano in the article «Implementation of controls against e-skimming (PCI DSS req. 6.4.3 and 11.6.1)‘, protection against attacks by e-skimming  can be implemented using different strategies, but it is very important that all elements required by requirements 6.4.3 and 11.6.1 are covered:

6.4.3 All payment page scripts that are loaded and solved in the consumer’s browser are managed as follows:
• A method is implemented to confirm that each script is authorized.
• A method is implemented to assure the integrity of each script.
• An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
11.6.1 A change- and tamper-detection mechanism is controlled as follows:
• To alert personnel to compromised modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
• The mechanism is designed to evaluate the HTTP headers and payment pages.
• The mechanism functions are usually as follows:
– At least weekly
OR
– Periodically (at the frequency defined in the entity’s targeted risk analysis, which is defined according to all elements specified in Requirement 12.3.1).

Terminology

One of the values provided by this new document is the clarification of concepts and terminology. Finally, the differences between a page that is not paid (any page that embeds a checkout page and your form fields), a payment page (a page that may contain one or more elements of a form intended to capture account data or to send that captured data for processing or authorization of the transaction) and a payment form (form with the fields used to capture the cardholder's account details).  Likewise, what is a script of a payment page (Javascript, VB Script or WASM components interpreted by the client's browser that can be used for advertising, product selection or security), clarifying that HTML or CSS components cannot be classified as such (as they are not programming languages).

Graphical description of a payment page and its components. Source: John Elliot – https://pcirocks.substack.com/p/what-exactly-is-a-payment-page

Using iframes on a checkout page. Note the similarity of this graph of the information supplement with that published by John Elliot

Also, here are some examples of HTTP headers that can impact the security of a payment page and that must be configured/monitored:

  • Content Security Policy (CSP)
  • X-Frame-Options (protection against clickjacking)
  • Strict Transport Security (HSTS)
  • X-XSS-Protection (XSS Filter)
  • X-Content-Type-Options (prevent MIME sniffing)
  • Set-Cookie

Scripts

It is clarified that the scripts can be loaded from a server controlled by the entity (first-party servers) or from a third party (third-party servers) which, in turn, can load them from other suppliers (four-party servers).

On the other hand, the two types of attacks that can compromise active content are explained: supply chain attacks (where the attacker compromises scripts from third parties who are uploaded on the trade page) or script injection attacks (where the attacker injects scripts modified and unauthorized on the payment page to exfiltrate sensitive data).

Once the script is injected, can work in a silent (capturing the data covertly without raising suspicion) or asking for the data entry twice (one where the script captures the data and exfiltrates it and another where it is recaptured to send it to the normal flow of operation).

Payment Page Scenarios

This section reminds us of that famous Visa document from 2014 (Processing e-commerce payments) where the different payment page scenarios were categorised. However: in 2025 this has not changed much and the categorisation remains similar:

  • Payment forms hosted by the merchant, including Merchant-Posted Payment y Direct-Post Payment.
  • Embedded payment forms (iframes)
  • Redirection
  • Full delegation (fully outsourced)

Based on this categorization are established responsibilities for the implementation of controls by the trade and its suppliers:

Applicability and responsibility of controls 6.4.3 and 11.6.1

Additional clarifications related to the PCI DSS SAQ A applicability criteria already discussed in PCI Hispano are also included (Changes in SAQ A of PCI DSS v4.0.1).

Best practices for minimizing the risks of using scripts from third parties

This document also includes a list of best practices to minimize the risk in the use of scripts provided by third parties, including:

  • Minimize the number of scripts to the strictly necessary
  • Move the scripts to isolated iframes
  • Limit the sources of scripts
  • Understand the behavior of scripts, and
  • Execute technical security validations periodically or continuously (code review, behavior analysis and / or monitoring at runtime)

Controls and techniques to meet requirements 6.4.3 and 11.6.1

As already advanced in PCI Hispano, there are several techniques to implement the security controls required by these requirements.

  • Content Security Policy (CSP) and Sub-resource Integrity (NIS)
  • Monitoring of web pages without agents (agentless) or with agents
  • Use of proxies

Evidence of compliance and best practices

And finally, the document includes a series of best practices for service providers and businesses as well as a guide for advisors and entities about the evidence necessary to demonstrate the correct implementation of the controls.

Conclusion

This information supplement was something that had been waiting for a long time. Requirements 6.4.3 and 11.6.1, being new to PCI DSS, did not have sufficient documentation and implementation experience as it does with other more "traditional" controls such as anti-malware solutions, firewalls, intrusion detection/prevention systems or file integrity monitoring.  For that reason, the indications, suggestions and best practices in the industry, centralized by the PCI SSC in these documents, become an indispensable tool to avoid problems derived from misinterpretations of the controls or partial implementation of solutions that can lead to a false sense of security and expose the entity to incidents.

From PCI Hispano we recommend reading the article What exactly is a Payment Page? from John Elliot, probably one of the most knowledgeable people in this field, who explained these concepts in 2023 and much of his work was included in this new information supplement.

Posted by David Acosta

Qualified Security Assessor (QSA) for PCI DSS, PCI PIN, PCI 3DS, P2PE and PCI TSP. CISSP, CISA, CISM, CRISC, C|EH, C|HFI.

Leave to Reply