The PCI Council has recently provided additional guidance on requirements 6.4.3 and 11.6.1 regarding e-commerce payment channels with a focus primarily on hardening these channels against the rise of e-skimming attacks.
We’re delivering a summary of what is found in that guidance and an attempt to clarify some of the remaining confusion surrounding these two requirements. This document guides entities assessing with SAQs A-EP, D, or D-SP, as well as a Report on Compliance.
This guidance is provided to help determine where these requirements can be applied and how to meet the expected security controls surrounding them.
CampusGuard has provided more streamlined guidance for merchants assessing with SAQ A in a separate document.
PCI DSS Requirement 6.4.3 Applicability
Requirement 6.4.3 applies to all scenarios where payment page scripts are loaded and executed in a consumer’s browser. The requirement mandates that:
- 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.
Scenarios Requiring Compliance with 6.4.3
- Merchant-Posted Payment Forms (SAQ D or Service Providers)
Payment form fields reside on the merchant’s/third-party service provider’s (TPSP’s) server and transactions are posted from the merchant’s server. This would include models where the web server makes an API call to a payment gateway/processor, or effectively any e-commerce implementation that is not eligible for SAQs A or A-EP.- 4.3 would apply to all scripts on the merchant’s webpage(s). Any unauthorized script modification poses a direct security risk.
- Direct Post Payment (SAQ A-EP or Service Providers)
Payment form fields reside on the merchant’s/TPSP’s server and transactions are posted from the user’s browser to the TPSP. This results in the original server that sends the blank form to the user’s browser never directly receiving or interacting with cardholder data, as the data flows directly from the cardholder’s browser to the validated payment gateway/processor.- Requirement 6.4.3 would apply to all scripts on the merchant’s webpage(s). Any unauthorized script modification poses a direct security risk.
- Embedded Payment Forms (iframes) – Parent Page Only (Service Providers)
A parent page hosting an iframe from a remote TPSP providing an embedded payment form.- Requirement 6.4.3 applies to any scripts found in the parent page hosting the iframe, ensuring they do not compromise the integrity of the iframe.
- Any scripts found inside the payment iframe content provided by the TPSP will be the responsibility of the TPSP.
- Redirection Mechanisms (Service Providers)
Any methods used for redirecting consumers to a TPSP payment form.- Requirement 6.4.3 would apply to all scripts found in the webpage performing the redirection, ensuring they do not compromise the redirection process.
- Single-Page Applications (SPAs) with Dynamic Content Loading (SAQ D or Service Providers)
Any SPA that dynamically loads a payment form.- Requirement 6.4.3 would apply to all scripts loaded by the SPA, ensuring they do not compromise the payment form.
PCI DSS Requirement 11.6.1 Applicability
Requirement 11.6.1 mandates that a change- and tamper-detection mechanism is deployed to:
- Alert personnel to unauthorized modifications to security-impacting HTTP headers and script contents of payment pages.
- Evaluate received HTTP headers and payment pages at least weekly (or based on a targeted risk analysis).
Scenarios Requiring Compliance with 11.6.1
- Merchant-Posted Payment Forms (SAQ D or Service Providers)
Payment form fields reside on the merchant’s/TPSP’s server and transactions are posted from the merchant’s server. This would include models where the web server makes an API call to a payment gateway/processor, or effectively any e-commerce implementation that is not eligible for SAQs A or A-EP.- 6.1 would apply to all scripts and headers on the merchant’s webpage(s). Any unauthorized script or header modification poses a direct security risk.
- Direct Post Payment (SAQ A-EP or Service Providers)
Payment form fields reside on the merchant’s/TPSP’s server and transactions are posted from the user’s browser to the TPSP. This results in the original server that sends the blank form to the user’s browser never directly receiving or interacting with cardholder data, as the data flows directly from the cardholder’s browser to the validated payment gateway/processor.- 6.1 would apply to all scripts and headers on the merchant’s webpage(s). Any unauthorized script or header modification poses a direct security risk.
- Embedded Payment Forms (iframes) – Parent Page Only (Service Providers)
A parent page hosting an iframe from a remote TPSP providing an embedded payment form.- 6.1 would apply to all scripts and headers on the parent page hosting the iframe.
- Scripts within the payment iframe are the responsibility of the TPSP.
- Redirection Mechanisms (Service Providers)
Any methods used for directing consumers to a TPSP payment form.- 6.1 would apply to all scripts and headers found in the webpage performing the redirection, ensuring they do not compromise the redirection process.
- Single-Page Applications (SPAs) with Dynamic Content Loading (SAQ D or Service Providers)
Any SPA that dynamically loads a payment form.
-
- 6.1 would apply to all scripts and headers found in the SPA, ensuring they do not compromise the payment form.
Final Thoughts
With the focus on protecting payment pages from e-skimming, this guidance provides much-needed clarity for anyone tackling these requirements for PCI compliance. If scripts or any other technology is used that can be subject to these types of attacks, they need to be protected and monitored to ensure the integrity of that payment channel.
Entities must assess their implementations accurately to determine the applicability of PCI DSS requirements 6.4.3 and 11.6.1. If an entity hosts payment scripts or loads scripts impacting payment page security, these requirements must be implemented to mitigate the risks of e-skimming and unauthorized modifications.
CampusGuard’s ScriptSafe solution strengthens your organization’s compliance with PCI DSS requirements 6.4.3 and 11.6.1 by safeguarding cardholder data from payment page browser scripts. It ensures script integrity by detecting and preventing unauthorized modifications while reviewing and validating scripts in real-time. Request a demo to see it in action!
