Skip to content
Emergency helpGet started
Compliance & Governance

PCI DSS 6.4.3 and 11.6.1: Payment Page Script Security

PCI DSS 4.0 requirements 6.4.3 and 11.6.1 explained: script inventory, authorization, integrity and tamper alerts, and how Cloudflare Page Shield helps.
By VigilbasePublished
Read the guideMore Topics

PCI DSS requirements 6.4.3 and 11.6.1 protect e-commerce payment pages from skimming scripts. Requirement 6.4.3 asks for a method to confirm that each script on a payment page is authorized, a method to assure its integrity, and an inventory of all scripts with a written justification for each. Requirement 11.6.1 asks for a change- and tamper-detection mechanism that alerts your staff to unauthorized changes to the security-impacting HTTP headers and script contents of payment pages, as the consumer's browser receives them. Both were best practices until 31 March 2025 and have been required since. Cloudflare's client-side security, formerly Page Shield, can help you meet them, and Vigilbase can operate it on a Managed Cloudflare account.

What do PCI DSS 6.4.3 and 11.6.1 require?

In the guidance of the PCI Security Standards Council (PCI SSC), 6.4.3 is designed to prevent skimming attacks before they happen, and 11.6.1 makes sure unauthorized changes are recognized and raise alerts. Together they focus on payment page scripts being authorized, checked for integrity and monitored for tampering, along with the security-impacting HTTP headers that protect the page.
1.Authorization (6.4.3): a method confirms that each payment page script is authorized. PCI SSC guidance says authorization can happen before a script is added or changed, or as soon as possible after a change.
2.Integrity (6.4.3): a method assures the integrity of each script. PCI DSS does not mandate a mechanism; its guidance gives Content Security Policy and Subresource Integrity as examples.
3.Inventory (6.4.3): an inventory of all scripts, with a written business or technical justification for why each one is necessary. It covers scripts loaded from your own environment and from third and fourth parties.
4.Tamper detection (11.6.1): a mechanism 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 consumer browser.
5.Frequency (11.6.1): the mechanism runs at least weekly, or at the frequency set in a targeted risk analysis under Requirement 12.3.1. PCI SSC recommends frequent or real-time monitoring where feasible.
6.11.6.1 does not ask you to install software on your customers' devices or browsers. It asks you to detect unexpected script activity on the pages you serve.

When did 6.4.3 and 11.6.1 become mandatory?

PCI DSS v4.0, published in March 2022, introduced both as new requirements that were best practices until 31 March 2025. PCI DSS v4.0.1, a limited revision published in June 2024, added applicability notes on payment page scripts but did not change that date, and v4.0 was retired on 31 December 2024. Since 31 March 2025, 6.4.3 and 11.6.1 have been required and must be fully considered during a PCI DSS assessment. Requirement 12.10.5 also expects your incident response plan to cover alerts from the payment page change- and tamper-detection mechanism.

Which pages and scripts are in scope?

Scope depends on how your checkout collects card data. PCI SSC's March 2025 information supplement sets out who is responsible for which scripts.
1.If you host the payment form, you are responsible for every script on your payment pages. The payment provider is responsible for any scripts it includes for its own services.
2.If you embed a payment provider's form in an iframe, the page that embeds it stays in scope. You are responsible for scripts on that parent page; the provider is responsible for scripts inside its iframe.
3.Where a script creates the iframe or performs a redirect, 6.4.3 and 11.6.1 apply to that script.
4.In a single-page application, scripts stay in memory as customers move between views, so the requirements apply to every view in the application, because any of them could affect the embedded payment form.
5.For merchants using a 3-D Secure (3DS) solution, 3DS scripts do not need validation against 6.4.3. Any script run for another purpose does.
6.If the payment provider handles all payment collection, for example through a link to pay on its own website, the merchant has nothing to do for 6.4.3 and 11.6.1.

What changed for SAQ A merchants?

SAQ A for PCI DSS v4.0.1, in its r1 revision, does not include 6.4.3 or 11.6.1. Instead, a merchant whose webpage includes a payment provider's embedded payment form must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. PCI SSC FAQ 1588 says the merchant can confirm this either by using techniques such as those in 6.4.3 and 11.6.1, deployed by the merchant or a third party, or by getting confirmation from its PCI DSS compliant payment provider that the embedded solution protects the payment page from script attacks when implemented as instructed. The criterion does not apply to merchants that redirect customers to the provider or fully outsource payments. Your acquirer or the payment brands decide which SAQ you use, and FAQ 1331, dated August 2026, says SAQ eligibility criteria should not be used as a guide to applicability in a Report on Compliance unless they agree.

What evidence do assessors look for?

The expected testing for 6.4.3 is to examine policies and procedures, interview responsible personnel, examine inventory records and examine system configurations. For 11.6.1, assessors examine the mechanism's system and configuration settings, the monitored payment pages and the results of monitoring, interview responsible personnel and, if you use one, examine the targeted risk analysis. A practical evidence pack looks like this:
1.A script inventory for each payment page and parent page, with an owner and a business or technical justification for every script.
2.Records of how each script was authorized, including changes approved as soon as possible after they happened.
3.The integrity method you use, such as a Content Security Policy allowlist, hashes, Subresource Integrity or page monitoring, and its configuration.
4.The tamper-detection configuration, showing which pages and security-impacting headers are evaluated and how often.
5.Alert history, and what was done about each alert, linked to your incident response plan.
6.Documented policies, procedures, roles and responsibilities for Requirements 6 and 11, and the targeted risk analysis if you do not evaluate weekly.

How Cloudflare client-side security (formerly Page Shield) helps

Cloudflare renamed Page Shield to client-side security in March 2026, and Page Shield policies are now called content security rules. When monitoring is on, Cloudflare adds a Content-Security-Policy-Report-Only header to a sample of HTML responses, and visitors' browsers report the scripts and connections each page loads. Cloudflare turns those reports into a list of the scripts running on your pages. Cloudflare's PCI DSS page says that to help with 6.4.3 and 11.6.1 you need Client-Side Security Advanced, the former Page Shield add-on.
1.Inventory: script monitoring is available on every plan. Business and higher plans add connection and cookie monitoring, page attribution showing where a script first appeared, and alerts for new resources and new domains.
2.Authorization: with Advanced, content security rules turn your allowlist into Content Security Policy headers. A rule with the Log action reports violations without blocking; switching it to Allow blocks resources that are not on the list. Changes to Page Shield policies, now content security rules, appear in Cloudflare audit logs.
3.Integrity: Advanced adds code change detection, and malicious script and connection detection based on threat intelligence and machine learning. Content security rules support hash sources but not nonces.
4.Alerts: new-resource and code change alerts are triggered daily, or immediately when configured with a zone filter, and new-domain alerts hourly. Advanced adds malicious resource alerts. Alerts go to email, webhooks or connected notification services.
5.Advanced also allows up to five content security rules and four Logpush jobs.
6.What stays with you: Cloudflare's documentation describes monitoring of scripts, connections and cookies. Requirement 11.6.1 also covers security-impacting HTTP headers, so agree with your assessor how header changes are detected. Someone still writes each script's justification and acts on each alert.

How Vigilbase runs client-side security for you

On a Managed Cloudflare account, Vigilbase can turn on client-side security, build the script inventory with your developers, run content security rules in Log mode until the violations are understood, and switch them to Allow with your approval. New-script, code-change and malicious-script alerts are investigated, and the record shows the investigation, the action taken and the verification. Coverage follows your package: Core works in business hours, while Priority and Critical run 24/7. If you buy Cloudflare Enterprise through Vigilbase, include Client-Side Security Advanced in the licence scope, and the proposal confirms it.

Responsibility and legal note

Vigilbase does not make you PCI DSS compliant and is not your assessor. It helps you operate the controls and produce evidence for 6.4.3 and 11.6.1. This guide summarizes PCI SSC and Cloudflare publications as available in October 2026. It is not legal or compliance advice: your Qualified Security Assessor, acquirer or the payment brands decide how PCI DSS applies to you.

Key Takeaways

✓Requirement 6.4.3 needs authorization, integrity and a justified inventory for every script that runs on a payment page.
✓Requirement 11.6.1 needs alerts on unauthorized changes to security-impacting HTTP headers and payment page scripts, at least weekly or at a frequency set by a targeted risk analysis.
✓Both have been required since 31 March 2025, and embedding a payment provider's iframe does not take the parent page out of scope.
✓Cloudflare's client-side security, formerly Page Shield, helps with these requirements when you have Client-Side Security Advanced.
✓Tools produce evidence; your team still justifies each script, approves changes and acts on alerts.

Sources

Get a free Cloudflare Checkup

An A–F grade for your Cloudflare account in about 2 minutes. Read-only: sign in with Cloudflare, and access is revoked when the scan finishes. The grade and free findings cost nothing; the full report is an optional upgrade.

Run the free Checkup

Related Solutions

Vigilbase services related to this guide

Managed Cloudflare packages

Learn more

Managed Cloudflare WAF

Learn more

Cloudflare pricing and plans

Learn more

HTTP Security Headers Checker

Learn more

Cybersecurity for e-commerce and retail

Learn more

Frequently Asked Questions

What does PCI DSS 6.4.3 require?

PCI DSS 6.4.3 requires that every payment page script loaded and executed in the consumer's browser is managed in three ways: a method confirms each script is authorized, a method assures each script's integrity, and an inventory of all scripts records a written justification for why each one is necessary.It applies to scripts loaded from your own environment and from third and fourth parties. Assessors examine your policies and procedures, inventory records and system configurations, and interview the people responsible.How a web application firewall worksA practical website protection guide

What does PCI DSS 11.6.1 require?

PCI DSS 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorized modification of the security-impacting HTTP headers and script contents of payment pages, as received by the consumer browser. It must run at least weekly, or at the frequency set in a targeted risk analysis.Your incident response plan should cover how you respond to its alerts. PCI SSC recommends frequent or real-time monitoring where feasible, because a malicious change can go unnoticed between checks.HTTP Security Headers CheckerManaged WAF operations and change control

Do 6.4.3 and 11.6.1 apply if we use a payment provider's iframe?

Yes, for the page that embeds the iframe. You are responsible for the scripts on that parent page, and the provider is responsible for the scripts inside its iframe. If you validate with SAQ A, you instead confirm that your site is not susceptible to script attacks that could affect your e-commerce systems.PCI SSC FAQ 1588 lets an SAQ A merchant confirm this with techniques such as those in 6.4.3 and 11.6.1, or with confirmation from its PCI DSS compliant payment provider. Your acquirer or the payment brands decide which SAQ applies.Website Security CheckA practical website protection guide

Is Cloudflare Page Shield enough for PCI DSS 4.0?

Cloudflare says client-side security, formerly Page Shield, can help with requirements 6.4.3 and 11.6.1 if you have Client-Side Security Advanced. It does not complete them on its own: you still justify each script, approve changes, cover security-impacting HTTP headers and respond to alerts, and your assessor decides whether the evidence is sufficient.Cloudflare Enterprise licensing explainedCloudflare Enterprise with Vigilbase

Can Vigilbase operate Cloudflare client-side security for us?

Yes, within a Managed Cloudflare package. Vigilbase can turn it on, build the script inventory with your developers, move content security rules from Log to Allow with your approval, and investigate alerts, with a record of the action taken and its verification.Core covers business hours; Priority and Critical run 24/7. Vigilbase does not make you PCI DSS compliant and does not replace your assessor.Compare Core, Priority and CriticalCoverage and incident response commitments

Related Topics

Network Security

What is WAF?

Network Security

Protect Your Website

Network Security

Managed WAF Services

Compliance & Governance

DORA compliance

Get Started

Ready to Improve Your Security?

Our team can help you implement the security measures discussed in this guide. Get expert guidance tailored to your organization.
Get started Continue Learning