Securing Payment Pages Under PCI
A shopper reaches checkout and starts typing a card number. The page in front of them was not delivered as a single file. It was assembled inside the browser from a dozen origins: the merchant's own bundle, a tag manager, a chat widget, an analytics library pulled from a content delivery network. One of those files changed overnight, because the vendor that publishes it was compromised upstream, and the new version carries a few lines that attach a listener to the card field. Every keystroke is copied into a variable. When the shopper clicks submit, that variable leaves the page as a request to a domain the merchant has never heard of, and the order completes normally.
Why the server sees nothing wrong
E-skimming executes entirely in the consumer's browser, which puts it outside the reach of server-side controls. TLS encrypts the exfiltration request as faithfully as the legitimate one, and a web application firewall inspects traffic arriving at the merchant's origin, where the stolen data never travels. The joint CISA and FBI e-skimming guidance notes that skimmer code varies enough in complexity that no fixed set of indicators of compromise reliably identifies it, which is why the warning signs it lists are downstream: customer fraud complaints after a purchase, an unfamiliar domain registration, edited JavaScript.
What Requirement 6.4.3 removes from the attack path
PCI DSS Requirement 6.4.3 governs every payment page script loaded and executed in the consumer's browser through three controls: a method to confirm that each script is authorized, a method to assure the integrity of each script, and an inventory of all scripts maintained with written business or technical justification for why each is necessary. It stopped being a best practice on 31 March 2025.
The inventory and its justifications shrink the population of scripts that can be tampered with, which is the cheapest control on the list and the most often deferred. Integrity checking, usually subresource integrity, makes the browser refuse a file whose hash no longer matches the one the merchant published. Authorization keeps a script from appearing without a decision behind it, and where that decision cannot come first, the standard accepts confirmation as soon as possible afterward.
What Requirement 11.6.1 is positioned to catch
Requirement 11.6.1 calls for a change and tamper detection mechanism that alerts personnel to unauthorized modification of the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser, performed at least weekly or at a frequency set by a targeted risk analysis under Requirement 12.3.1. Version 4.0.1 narrowed the language to security-impacting headers, lifting the obligation to alert on every header change.
The phrase carrying the weight is "as received by the consumer browser." Preventive controls operate on what the merchant publishes, while detection has to operate on what the shopper renders, because that is where injected inline script, a weakened Content Security Policy, and a skimmer assembled at runtime become visible. PCI SSC states plainly that its list of detection mechanisms is not exhaustive, and that any one of them is not necessarily complete on its own.
Content Security Policy and subresource integrity answer the integrity clause in 6.4.3. On their own, they are not the runtime tamper detection that 11.6.1 asks for.
Where the iframe boundary places responsibility
The applicability notes are the part most merchants read past. Both requirements reach the merchant's own webpage when that page embeds a payment service provider's page or form in an iframe, and they do not reach the merchant for scripts inside that iframe, which the provider manages and evidences under Requirement 12.9. Same-origin policy stops parent page script from reading the iframe's fields directly. It does nothing to stop a script on the parent page from drawing an overlay above the iframe or changing the source the frame loads from, and that surface belongs to the merchant.
The attestation sitting behind SAQ A eligibility
SAQ A no longer lists 6.4.3 and 11.6.1 among the requirements a merchant validates. An eligibility criterion sits in their place: the merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems. PCI SSC FAQ 1588 confirms the criterion applies only where the merchant's webpage embeds a provider's payment form, not to redirects or fully outsourced flows, and that a merchant confirms it either by deploying techniques such as those in 6.4.3 and 11.6.1 or by obtaining confirmation from a PCI DSS compliant provider whose solution includes them.
Both routes end in evidence that neither produces by default. Asking which SAQ drops the requirement settles a scoping question. The question an assessor puts is narrower: what supports the confirmation the merchant has already signed.
Sources
Payment Card Industry Data Security Standard: Requirements and Testing Procedures, Version 4.0.1, PCI Security Standards Council, June 2024. https://www.pcisecuritystandards.org/document_library/
Information Supplement: Payment Page Security and Preventing E-Skimming, Guidance for PCI DSS Requirements 6.4.3 and 11.6.1, PCI Security Standards Council, March 2025. https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming
FAQ 1588: How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts? PCI Security Standards Council, February 2025. https://www.pcisecuritystandards.org/faqs/1588/
Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A, PCI Security Standards Council, January 2025. https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
E-Skimming: Skimming Online Customer Payment Data From Website Checkout Forms, Cybersecurity and Infrastructure Security Agency with the Federal Bureau of Investigation. https://www.cisa.gov/sites/default/files/publications/NCSAM_ESkimming_2020.pdf
Disclaimer
This article is provided for general information and does not constitute compliance, legal, or assessment advice. PCI DSS requirements are interpreted in the context of a specific environment, and PCI SSC does not enforce compliance or determine whether a given implementation is compliant. Merchants and service providers should confirm their validation obligations, applicable SAQ, and reporting responsibilities with their acquirer, payment brand, or a Qualified Security Assessor. AKATI Sekurity operates as a QSA and ASV.
