PCI DSS 4.0: requirements 6.4.3 and 11.6.1 for checkout scripts

Disclaimer: this article explains the PCI DSS standard and the official publications of the PCI Security Standards Council. It is not a compliance opinion and does not replace your Qualified Security Assessor (QSA) or acquirer.

PCI DSS v4.0.1 has two requirements for the JavaScript that runs on an online store's payment page. Requirement 6.4.3 says each script on that page must be authorized, have its integrity verified and be listed in an inventory with a justification. Requirement 11.6.1 calls for a mechanism that detects and alerts on unauthorized changes to the security-impacting HTTP headers and to the content of the page's scripts, as received by the customer's browser, at least once a week or at the frequency set in a risk analysis. Both stopped being best practices and became mandatory on March 31, 2025. For merchants who validate with SAQ A, the PCI SSC replaced the two requirements in 2025 with an eligibility criterion about script attacks.

The scope of this article is PCI DSS v4.0.1 (June 2024), the current version I was able to confirm in October 2026, and the PCI SSC publications on SAQ A from January and February 2025. Where it quotes the standard, the wording is paraphrased; the binding text is the original in the PCI SSC document library. For the wider context of site security, see the guide to website security basics.

Why these requirements exist

A payment page usually loads scripts from several origins: the site itself, libraries on a CDN, analytics, tag managers. The guidance for 6.4.3 explains that seemingly harmless scripts can be used to load malicious code that reads card data in the customer's browser and sends it out. This attack is called e-skimming. Requirement 11.6.1 starts from the same premise and adds that, because pages are assembled in the browser from several sources, the only place to notice the change is the page as the browser receives it (PCI DSS v4.0.1, requirements 6.4.3 and 11.6.1, guidance columns).

Versions and dates

There is a small discrepancy between PCI SSC texts on the effective date of the new SAQ A: the January announcement says March 31, 2025, and the February post about the FAQ says April 1, 2025.

Requirement 6.4.3: authorization, integrity and inventory

All scripts loaded and executed in the customer's browser on the payment page must be managed as follows (PCI DSS v4.0.1, requirement 6.4.3, paraphrased):

• a method is in place to confirm that each script is authorized;

• a method is in place to assure the integrity of each script;

• an inventory of all scripts is maintained, with a written business or technical justification of why each one is necessary.

The applicability notes and the guidance add practical points:

• The requirement applies to scripts from the entity's own environment and to third-party and "fourth-party" scripts (the ones a third-party script loads).

• If your page embeds a provider's payment form (for example, in an iframe), the requirement applies to the scripts on your page. The scripts inside the provider's form are the provider's responsibility, and the guidance says the merchant should expect evidence from the provider that it meets the requirement.

• Authorization can be manual or through an automated workflow. When it is not feasible to authorize a script before it changes, the authorization should be confirmed as soon as possible after the change.

• The integrity mechanisms given as examples are SRI, CSP and script or tag management systems that prevent malicious code from running. The list is not closed.

• For payment pages loaded in an iframe, the guidance suggests using the parent page's CSP to restrict where the iframe can be loaded from.

In revision 4.0.1, the PCI SSC clarified that the inventory justification can be business or technical, added the three notes on iframes and the guidance on authorizing after the change when authorizing before is not possible (Summary of Changes v4.0 to v4.0.1, August 2024).

Requirement 11.6.1: change and tamper detection

Requirement 11.6.1 calls for a change and tamper detection mechanism that (PCI DSS v4.0.1, requirement 11.6.1, paraphrased):

• alerts personnel to unauthorized 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 customer's browser;

• evaluates the received HTTP headers and payment page;

• runs at least once a week, or at the frequency defined in the entity's targeted risk analysis, performed according to requirement 12.3.1.

Version 4.0 referred to "HTTP headers and the contents of payment pages" and to "once every seven days". Version 4.0.1 narrowed the target to security-impacting headers and script contents, and replaced the interval with "weekly" (Summary of Changes v4.0 to v4.0.1). The standard does not list which headers these are; CSP is the most obvious case, because the guidance itself says a change to the CSP can indicate tampering.

The applicability notes make clear that the intent is not to install software on the customer's computer or browser, but to use techniques like the ones in the examples. The examples in the guidance, which can be combined (PCI DSS v4.0.1, 11.6.1):

• CSP violation reports sent through the report-to or report-uri directives;

• monitoring changes to the CSP itself;

• external monitoring by systems that request and analyze the pages (synthetic monitoring) and alert on changes to the JavaScript;

• a tamper-resistant detection script embedded in the page that alerts on and blocks malicious behavior;

• reverse proxies and CDNs that detect changes to scripts.

The standard warns that this list is not complete and that none of these mechanisms, on its own, is necessarily a complete detection and alerting solution.

Who it applies to

PCI DSS applies to all entities that store, process or transmit cardholder data, or that can affect the security of that data: merchants, processors, acquirers, issuers and other service providers. Who needs to validate compliance, and how, is decided by the organizations that manage compliance programs, such as the card brands and acquirers (PCI DSS v4.0.1, introduction). The table sums up how the two requirements fit each way of integrating payment, according to the standard and FAQ 1588. Which questionnaire (SAQ) or report applies to you is settled with your acquirer.

What changed in SAQ A in 2025

SAQ A is the shortest self-assessment questionnaire, used by merchants who outsource all handling of card data. In January 2025 the PCI SSC announced a new version of SAQ A for PCI DSS v4.0.1 that (PCI SSC, January 30, 2025):

• removed requirements 6.4.3 and 11.6.1 from the questionnaire, along with 12.3.1, the risk analysis that supports 11.6.1;

• added an eligibility criterion: the merchant confirms that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.

The Council makes it clear that the change only affects how merchants report in SAQ A and that it does not remove the requirements from the standard. In the words of the announcement, the changes "do not remove or diminish the underlying requirements within PCI DSS".

FAQ 1588, from February 2025, explains how to meet the criterion (FAQ 1588; PCI SSC post about the FAQ):

• The criterion applies to merchants whose page embeds a provider's payment form, for example in an iframe. It does not apply to merchants who redirect the customer to the provider or who outsource payment entirely.

• There are two paths: use techniques such as those in requirements 6.4.3 and 11.6.1, applied by the merchant or by a third party; or obtain confirmation from the payment provider, which must be PCI DSS compliant, that its solution, implemented according to its instructions, protects the merchant's page against script attacks.

• A vendor of scripts that have nothing to do with payment and cannot affect the security of card data is not considered a third-party service provider (TPSP) for SAQ A purposes.

• The merchant should confirm with its acquirer or the card brands whether it needs to submit an SAQ and which one.

Merchants who validate with other questionnaires or with an assessor's report still answer for both requirements. In the version 4.0 SAQ A-EP, for example, 6.4.3 and 11.6.1 appear with the same requirements (SAQ A-EP v4.0). Check the current version of the questionnaire in the PCI SSC document library before answering.

How to implement it in practice

The steps below are a recommended way to organize the work, based on the standard's own examples. They are not an official PCI SSC procedure, and how to evidence each item should be agreed with your assessor.

1. Map the payment pages: the page with the card form and, if the form is a provider's iframe, the merchant page that embeds it. Include variations (mobile, languages, A/B tests).

2. Build the inventory. For each script: address, origin (first party, third party, loaded by a third party), purpose, justification, internal owner and approval date. Scripts with no justification come off the page.

3. Define the authorization process. It can be a step in code review or an approval workflow in the tag manager. For scripts the vendor changes without notice, record the confirmation right after the change, as the guidance allows.

4. Apply integrity controls. SRI (the integrity attribute) works for static, versioned files: the browser rejects the file if its content changes (MDN: SRI). For the rest, a CSP limits where the page loads scripts from and where it can send data, and the frame-src directive limits where the payment iframe can come from. Details in the article on HTTP security headers.

5. Set up 11.6.1 detection: CSP violation reports, periodic comparison of the received headers and scripts with the approved version, or another mechanism from the standard's list. If the frequency is less than weekly or different from it, document the 12.3.1 risk analysis.

6. Decide who receives the alerts and what to do with them: confirm whether the change was authorized, update the inventory or trigger the incident response plan.

7. Keep evidence: inventory with history, approvals, mechanism configuration and records of handled alerts.

An example CSP for a merchant page that embeds a provider's form. The domains are fictitious; use the ones your provider documents.

Content-Security-Policy:
  script-src 'nonce-{generated per response}' 'strict-dynamic';
  frame-src https://payment.provider.example;
  connect-src 'self' https://api.provider.example;
  form-action 'self' https://payment.provider.example;
  object-src 'none';
  base-uri 'none';
  report-to csp

With this policy, the browser only runs scripts that carry the response's nonce (and the ones they load), only opens the payment iframe on the provider's domain, only makes network calls to the site itself and the provider's API, and reports violations. In stores with many marketing scripts, the restricted connect-src is usually what needs the most tuning.

Limits of each control

• SRI does not work for scripts the vendor updates at the same address: with every legitimate update, the hash stops matching and the browser blocks the file.

• A CSP with a domain allowlist permits any code coming from an allowed domain. If the allowed vendor is compromised, the policy does not stop the attack.

• External monitoring sees the page the bot received. Content that varies by country, device, cookie or time of day may not show up in the check.

• The standard accepts a weekly check, but an attack can stay active between one check and the next. The 12.3.1 risk analysis exists to decide whether the page calls for a higher frequency.

• Meeting 6.4.3 and 11.6.1 does not make the rest of the environment PCI DSS compliant, and no tool replaces the assessor's evaluation or the acquirer's acceptance.

How to check your site

To start by hand, open the payment page with DevTools, filter the Network tab by JS and note each script, its origin and what requested it (the Initiator column shows this). Then check the response headers with curl -sI and see whether there is a CSP.

WebVyze's paid plans include an inventory of scripts on checkout pages tied to requirements 6.4.3 and 11.6.1, along with scheduled audits and alerts. WebVyze only reads public pages and never changes the site, so it shows what a visitor receives and cannot see what is inside the provider's iframe or your internal approval processes. It helps you build and maintain the evidence; it does not certify PCI DSS compliance.