PCI DSS requirements 6.4.3 and 11.6.1 apply to scripts on payment web pages: every script must be authorized, verified for integrity and recorded in an inventory with a justification, and unauthorized changes to the page and to HTTP headers must be detected. These are "future-dated" requirements: they were recommendations and became mandatory on 31 March 2025. For organizations that accept cards online, the deadline has already passed.
Why these requirements exist
Attacks of the e-skimming type (Magecart-style) rely on injecting malicious JavaScript into the payment page: the script quietly copies card data directly in the buyer's browser. The source can be a breach of the site itself or a compromised third-party library: analytics, a chat widget, A/B testing, a tag manager. Traditional server-side defenses do not see such an attack, because the malicious code runs on the client side. The PCI SSC guidance describes the goal of the requirements as preventing e-skimming by making sure that payment page scripts are approved, verified for integrity and monitored.
Timeline: what "future-dated" means
When PCI DSS v4.0 was released, some of the new requirements were marked as best practices until a certain date. For requirements 6.4.3 and 11.6.1 (and also 12.3.1), that date was 31 March 2025, as the PCI SSC states directly. The current version is v4.0.1, but the date for these requirements has not changed. This means that during an assessment of compliance (a QSA audit or a self-assessment), their implementation is checked as mandatory.
Requirement 6.4.3: managing scripts
This requirement covers scripts that are loaded and executed in the buyer's browser on payment pages. In essence, it requires three things:
- Authorization. There must be a method that confirms each script is permitted to run.
- Integrity. There must be a method that ensures the content of the script has not been altered.
- Inventory. A list of all scripts is maintained, with a written business or technical justification for why each one is needed.
Important: the list includes both scripts from your own domain and third-party scripts loaded from external servers, as well as those pulled in at the second level (a script that loads another script).
Requirement 11.6.1: detecting changes
This requirement calls for a mechanism that alerts personnel to unauthorized changes to security-relevant HTTP headers and to the content of payment pages as received by the consumer's browser. The check is performed periodically; the standard ties the frequency either to a defined interval or to the results of a targeted risk analysis (requirement 12.3.1). For the exact wording and the permitted frequency, check the text of PCI DSS v4.0.1 on pcisecuritystandards.org. In practice, auditors expect you to prove that a change would not go unnoticed.
Who it applies to: full assessment and SAQ A
The requirements apply to organizations whose payment pages are in the scope of PCI DSS. For merchants completing the SAQ A self-assessment, the situation is special. According to the PCI SSC FAQ, requirements 6.4.3 and 11.6.1 were removed from SAQ A, but they remain in the standard. Instead, a new eligibility criterion was introduced: the merchant must confirm that its website is not vulnerable to script-based attacks. This can be done in two ways: by applying technical measures similar to 6.4.3 and 11.6.1 (on their own or with a third party), or by obtaining written confirmation from a PCI-compliant third-party service provider (TPSP) that its solution, when properly implemented, protects the page against such attacks. The criterion applies to cases where the merchant's page embeds the provider's payment form (for example, in an iframe); it does not apply when the buyer is redirected to the processor's page. Check with your acquirer and payment brands which self-assessment form fits you.
For SAQ A-EP and for a full assessment (ROC), requirement 6.4.3 remains directly applicable.
How to meet the requirements: a practical plan
- Identify the payment pages. Which URLs accept and process card data, including embedded forms and redirects.
- Build the script inventory. Collect automatically everything that is actually loaded in the browser (not what is written in the documentation): your own files, third-party domains, loading chains.
- Get a justification for each script. Who owns it and why it is needed on the payment page. Remove anything that cannot be justified.
- Ensure authorization and integrity. Typical technical controls: a Content Security Policy (CSP) with an allowlist of sources; Subresource Integrity (SRI) for static external scripts; hosting critical scripts on your own infrastructure. Note that SRI is not suitable for scripts that the vendor changes often and dynamically.
- Set up monitoring (11.6.1). Continuously track the content of the pages and headers as the user sees them, and alert on deviations from the baseline.
- Embed the process. A new script on a payment page goes through approval and updates the inventory and the monitoring baseline. Without this, the inventory goes out of date within a month.
- Keep evidence. The inventory, alert logs, change decisions: the auditor will need artifacts for the assessment period.
Common difficulties
- Hidden dependencies. A third-party script loads several more. Static analysis of the source code will not show them; you need an analysis of what actually executes in the browser.
- Dynamic changes by vendors. Third-party services update their code without notice, which breaks SRI and triggers false alarms.
- CSP for show. A policy that is too permissive, with broad exceptions, exists formally but gives no protection.
- No owners. Marketing adds tags, and information security finds out during the audit.
Which tools help
The requirements can be covered with a combination of CSP, SRI and your own monitoring scripts, but maintaining such a setup is labor-intensive. Specialized client-side security solutions automate the inventory, integrity control and alerting. In the AST Cyber Lab portfolio, DPA FAST from DPA Analytics is a solution for front-end and JavaScript protection. Details of its capabilities and applicability to your payment scheme should be confirmed on the product page or with our specialists.
If you are only building a secure development process, start with the big picture: DevSecOps: Where to Start and the overview of AppSec tool classes. Control of front-end dependencies (npm packages) is a task for SCA, while the extended requirements of section 6 of PCI DSS can be checked as part of an application security assessment.
This article is for informational purposes only and is not legal advice.
What to show the auditor
A QSA assessor evaluates artifacts, not intentions. For 6.4.3 and 11.6.1, prepare in advance:
- an up-to-date inventory of scripts for each payment page, with justifications and owners;
- a description of the authorization method and integrity control (CSP policy, list of SRI hashes, approval procedure);
- a description of the change detection mechanism: what is monitored, how often, and who receives the alerts;
- logs of alerts and of incident review for the assessment period;
- a change procedure showing that a new script cannot reach the page bypassing approval.
If some scripts are provided by your payment service provider, request written confirmations from it and document the division of responsibility: which parts are its zone and which are yours.
Where to start right now
If the deadline has passed and the process is not yet in place, act in this order: over the next one to two weeks, build a real inventory of the payment page scripts; remove everything that cannot be justified; enable change monitoring so that you start accumulating evidence; in parallel, tighten the CSP and introduce an approval procedure for new scripts. Do not wait for an ideal architecture: partial implementation with a transparent plan is better than no controls at all. Agree on the schedule and on any acceptable compensating measures with your QSA and your acquirer.
Frequently asked questions
From what date are requirements 6.4.3 and 11.6.1 mandatory?
Do we need to comply if we use the payment provider's iframe?
Is a CSP alone enough?
Does PCI DSS apply to organizations in Central Asia?
Do you accept card payments on your website or in your app? AST Cyber Lab experts can help you assess how to meet 6.4.3 and 11.6.1 in your specific payment scheme.
Sources
- PCI SSC Blog: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025
- PCI SSC FAQ 1588: SAQ A eligibility criterion and payment page scripts
- PCI SSC Blog: FAQ Clarifies New SAQ A Eligibility Criteria