PCI DSS for E-commerce Payment Page Scripts Guide: Requirements 6.4.3 and 11.6.1

E-skimming attacks steal card data in the shopper's browser, so a payment page can be fully compliant on the server and still leak every card typed into it. PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1 respond by requiring every payment page script to be authorised, integrity-assured and justified in an inventory, and by requiring a mechanism that detects unauthorised changes to scripts and security-impacting HTTP headers as the browser receives them. Both became mandatory on 31 March 2025, and PCI SSC published dedicated guidance in March 2025. This guide covers scope by integration type, what each requirement asks, the SAQ A change, who owns which scripts, the identities that can alter a payment page, implementation, and the evidence assessors request. It is written for e-commerce, application security and compliance teams, and goes deeper on the audit side than the Client-Side Security Guide.

Key takeaways

• Scope follows the integration type. Merchant-hosted, direct-post and iframe-embedded payment pages are in scope for the merchant's parent page; pure redirects and fully outsourced payment links largely are not, but scripts that perform a redirect or create an iframe are.
• 6.4.3 has three elements. Each script must be authorised, its integrity assured, and listed in an inventory with a written business or technical justification.
• 11.6.1 watches what the browser receives. It covers both script contents and security-impacting headers such as Content-Security-Policy, at least weekly or at a frequency set by targeted risk analysis.
• SAQ A dropped the requirements, not the risk. Since 31 March 2025 SAQ A merchants instead confirm their site is not susceptible to script attacks, using 6.4.3/11.6.1-style techniques or confirmation from a compliant service provider.
• Payment pages change through identities. Tag manager admins, CDN and storage write keys and CI/CD deploy tokens can all alter what the browser loads; control them as part of 6.4.3.

What it is and who it applies to

PCI DSS v4.0 introduced 6.4.3 and 11.6.1 as future-dated requirements, best practice until 31 March 2025 and assessed in full since. PCI SSC's information supplement "Payment Page Security and Preventing E-Skimming: Guidance for PCI DSS Requirements 6.4.3 and 11.6.1" (version 1.0, March 2025) explains scope and methods; it supplements the standard and does not replace it. The supplement defines a payment page as a web interface with form elements intended to capture account data or submit it for processing, whether a single document, a document in an iframe, or several iframes inside a non-payment page. A payment page script is any script the browser processes on that page, including those interacting with the DOM; HTML and CSS are not scripts, but WebAssembly can be.

The supplement also notes that 3-D Secure scripts used only for 3DS functions are exempt from 6.4.3 validation. For whole-standard context see the PCI DSS 4.0 Guide, and for scope reduction the PCI DSS Scoping and Network Segmentation Guide.

Structure and key requirements

Requirement 6.4.3

All payment page scripts loaded and executed in the consumer's browser are managed so 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 for why each is necessary."

The standard does not prescribe the authorisation method, the approver or whether it is manual or automated. The supplement accepts authorisation before a script is added or changed, or as soon as possible after, with workflow tickets or retained approvals as evidence.

Requirement 11.6.1

A change- and tamper-detection mechanism alerts personnel to unauthorised modification of the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser, evaluates the received headers and page, and runs at least weekly or at a frequency defined by a 12.3.1 targeted risk analysis. The supplement lists headers that may be security-impacting depending on architecture: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options, Set-Cookie, Access-Control-Allow-Origin, Referrer-Policy, Permissions-Policy and the Cross-Origin policy headers. It warns that changes can persist undetected between checks and recommends frequent or real-time monitoring where feasible.

Methods compared

See the Subresource Integrity Guide and the Content Security Policy Guide for configuration detail.

The SAQ A change

On 30 January 2025 PCI SSC removed 6.4.3, 11.6.1 and 12.3.1 from SAQ A, effective 31 March 2025, and added an eligibility criterion that the merchant confirm "their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)". FAQ 1588 (February 2025) says the merchant can meet it with protective techniques such as those in 6.4.3 and 11.6.1, deployed by itself or a third party, or with confirmation from a PCI DSS compliant service provider that its embedded payment page or form includes script-attack protections when implemented as instructed. The criterion applies to merchants embedding a provider's page or form, for example in an iframe, not to merchants that redirect or fully outsource. PCI SSC stresses that the change affects reporting only and the requirements remain in the standard; confirm validation obligations with your acquirer.

Identity and NHI requirements

Most e-skimming begins with someone, or something, gaining the ability to change a script. Authorisation under 6.4.3 is only meaningful if the identities that can publish code to the payment page are controlled.

• Storage and CDN write credentials: in the AI Agent Retail Card Theft Campaign, an AWS access key with write permissions let attackers modify the S3 bucket behind a store's CDN and serve skimmers from it. Restrict write access to the deployment pipeline's short-lived role and alert on any other writer.
• Tag manager and marketing platform accounts: anyone who can publish a tag container can add a script to checkout. Require MFA, limit publish rights, and exclude payment pages from tag manager containers where possible.
• CI/CD deploy tokens: pipeline identities that push front-end bundles are payment page change agents; scope them to the repository and environment and protect them as described in the CI/CD Pipeline Identity Security Guide.
• Third-party script providers: the vendor's own build and hosting identities are outside your control, which is why dynamic third-party scripts need CSP limits, monitoring or iframe isolation.
• Browser-held tokens: a malicious script reads anything in localStorage; keep session and API tokens in HttpOnly cookies or behind a backend-for-frontend.

Implementation steps

1. Identify every payment page and its integration type, including mobile web, guest checkout and regional storefronts.
2. Discover scripts as the browser sees them. Crawl each checkout path with a headless browser and record every script source, inline script and the scripts they load in turn; repository review alone misses tag manager and vendor injections.
3. Build the inventory. For each script record owner, source, purpose, business or technical justification, version or hash, and the approval reference. Remove scripts nobody can justify.
4. Set authorisation workflow. Route script additions and changes through change tickets or pull requests with named approvers, and include tag manager publishing in the same process.
5. Apply integrity controls. Add SRI to static, versioned files; use CSP with hashes or nonces for first-party inline code; move dynamic third-party code out of the payment page or into isolated iframes.
6. Deploy CSP in Report-Only first. Collect reports for two to four weeks, tune the policy, then enforce; keep Report-Only running alongside as an early warning. Rollback is reverting to Report-Only.
7. Deploy 11.6.1 monitoring that compares received scripts and headers against the inventory and alerts on change. Decide the frequency: weekly is the minimum, but a short targeted risk analysis justifying near real-time checks is the safer default for high-volume stores.
8. Connect alerts to incident response. 12.10.5 expects alerts from change-detection mechanisms in the response plan; rehearse the steps in the Web Skimming Incident Playbook.
9. Agree responsibilities with providers. Record who covers parent page scripts and who covers the iframe, and obtain written confirmation from the provider for SAQ A eligibility where relevant. See the PCI DSS for Service Providers and Responsibility Matrix Guide.

Decision guidance

• Change the integration or secure the page: moving from a merchant-hosted form to an embedded iframe or redirect shrinks what the merchant must control, but the parent page still needs 6.4.3 and 11.6.1. For small merchants with few scripts, a redirect or fully outsourced payment link removes most of the burden; for large retailers whose checkout is a core product, keeping the form and investing in monitoring is often the better trade.
• Agentless vs agent-based monitoring: synthetic monitoring adds nothing to the page and is simple to evidence, but sees only what its scheduled runs encounter. Agent-based monitoring sees real sessions in near real time but is itself a payment page script that must be inventoried, authorised and integrity-checked.
• Build or buy: a spreadsheet inventory, CSP reporting into your SIEM and a scheduled headless browser comparison can satisfy both requirements on a simple site. Many scripts across many storefronts usually justify a dedicated client-side monitoring service; evaluate how it handles authorisation workflow and header monitoring, not only script detection.
• Frequency: if you choose anything other than real-time detection, write the 12.3.1 analysis around transaction volume, the number of third-party scripts and how quickly you could respond, and review it at least every 12 months.

Evidence and assessment

Metrics that show the controls work: percentage of payment page scripts with owner and justification; number of unapproved scripts detected per month; percentage of scripts covered by SRI or CSP hash or nonce; median time from tamper alert to triage; monitoring coverage (payment pages monitored out of total); CSP violation reports per day after tuning.

Mapping to other frameworks

Common pitfalls

• Inventory from the repository only. Tag managers and vendor scripts load further code at runtime; the inventory must reflect what the browser actually executes.
• Assuming an iframe removes all scope. The parent page and any script that creates the iframe remain the merchant's responsibility.
• SRI on dynamic vendor scripts. The vendor updates the file, the hash fails, checkout breaks, and the team removes SRI everywhere. Isolate or proxy dynamic scripts instead.
• Headers left out of monitoring. 11.6.1 covers security-impacting headers; an attacker who relaxes the CSP header first can then inject freely.
• Weekly scans by default. A skimmer that runs for six days between checks still collects six days of cards; justify the frequency, do not inherit it.
• Uncontrolled write access to static hosting. Long-lived keys with write rights to the bucket or CDN origin bypass every code review, as the retail card theft campaign showed.

Practitioner checklist

• List every payment page and its integration type, and agree scope with your QSA or acquirer.
• Crawl checkout flows to discover the scripts the browser really loads.
• Maintain a script inventory with owner, justification, hash or version and approval reference.
• Route script and tag changes through an approval workflow with named approvers.
• Apply SRI to static files and CSP with hashes or nonces; isolate dynamic third-party code.
• Run CSP in Report-Only before enforcing, with report-to and Reporting-Endpoints configured.
• Deploy 11.6.1 monitoring of scripts and security-impacting headers at a justified frequency.
• Lock down tag manager, CDN, storage and pipeline identities that can change payment pages.
• Wire tamper alerts into the incident response plan and exercise it.
• Hold written responsibility splits and SAQ A confirmations from payment providers.

Standards and references

• PCI SSC: Payment Page Security and Preventing E-Skimming information supplement
• PCI SSC: Document Library (PCI DSS v4.0.1)
• PCI SSC: Important updates for merchants validating to SAQ A
• PCI SSC: FAQ clarifies new SAQ A eligibility criteria
• MDN: Subresource Integrity
• MDN: Content-Security-Policy-Report-Only
• OWASP: Application Security Verification Standard 5.0
• MITRE ATT&CK: JavaScript

Related NHI Mgmt Group resources: Client-Side Security Guide · PCI DSS 4.0 Guide · Web Skimming Incident Playbook · PCI DSS Requirements for Service Accounts and NHIs Guide · Cybersecurity for Retail and Ecommerce Guide