What the requirements ask
PCI DSS version 4.0.1 requirement 6.4.3 says that every script loaded and executed in the consumer's browser on the payment page is authorised, that its integrity is assured, and that an inventory with a written business justification for each script is maintained. Requirement 11.6.1 says a mechanism detects and alerts on unauthorised modification to the security-impacting HTTP headers and to the payment page content as the browser receives it, and that it runs at least weekly or at a frequency set by a targeted risk analysis. Both became mandatory on 31 March 2025. Neither names a product, and neither is satisfied by buying one.
The definition doing the most work is the payment page itself. It includes the page that loads a hosted field or iframe from a payment provider, not only the frame that captures the card. That single sentence decides whether a merchant that outsourced card capture is in scope for 11.6.1, and the answer is that it is.
The page we built
We assembled a test merchant page in our laboratory: hosted payment fields from a common gateway in test mode, a tag manager container, two analytics tags, a consent manager, a chat widget and a trial of a session-replay tool. Nothing exotic. It is the stack a marketing team assembles over a year on a page nobody is defending, and we built it precisely because we wanted the ordinary case rather than an interesting one.
What the browser actually loaded
- Script entries visible in the page source: 9. Distinct script requests the browser made on first load: 38.
- The tag manager container is one line in the source and a loader at run time. It brought in 14 further scripts, three of which came from template defaults we had never configured and could not have justified in writing.
- The chat widget pulled a dependency from a content delivery network we had no relationship with — a fourth party, reached through a third party, on the payment page.
- The consent manager loaded a measurement script before any choice was recorded, which is a consent problem and an inventory problem at the same time.
- One tag fired for roughly 20 per cent of sessions under an A/B tool. An inventory taken from a single page load will never see it, and will be wrong by construction rather than by carelessness.
The count we got wrong
Our first inventory listed 9 scripts. It was taken from the page source, it matched the way our own engineer described the page, and it was approved internally. It was also wrong by a factor of four. The container is a loader, and reading the source tells you what the page intended to load rather than what ran. The method now starts from the network log across repeated loads, with different consent choices and a cleared cache, and reconciles back to the source and the container configuration. Never the other way round.
The page source lists what the merchant intended to load. The network log lists what the browser actually ran
What the controls look like when they hold
- A Content Security Policy with an explicit script-src allowlist and per-request nonces, deployed in report-only mode first and enforced once the reports are clean.
- Subresource Integrity hashes wherever the vendor publishes versioned files. Several vendors do not: they serve a rolling latest at a fixed address, which no hash can cover, and the allowlist carries that risk alone.
- A weekly synthetic fetch that hashes the served document and the security-impacting response headers, alerts on any change, and retains the results with timestamps as assessment evidence.
- Change control that treats a tag manager publish as a code deployment, because that is what it is. The person who can add a script to a payment page without a code review is the control gap.
Two things worth saying plainly
The first is noise, and here our laboratory is no guide at all. On our page the report-only volume was trivial. On a live estate it will not be: the majority of report-only violations come from browser extensions injecting into the page, and separating those from a real unauthorised script is ordinary work measured in days. We have not done that filtering at production volume and we are not going to claim we have.
The second is scope. Moving card capture into a hosted field reduces the assessment surface and every merchant should do it, but it does not remove 11.6.1 from the page that loads the frame. The page is still the page. What we prepare is the inventory, the justification, the policy and the monitoring evidence. The assessment itself is signed by a Qualified Security Assessor the merchant engages. We do not assess, and a firm that both builds the evidence and signs the opinion is a firm with a conflict it cannot document its way out of.