Client-Side Supply Chain: CSP, SRI and PCI DSS 6.4.3

Q: What is client-side supply chain security and why do build-time controls miss it?

Client-side supply chain security is the practice of controlling and verifying the third-party code that executes in a customer’s browser, as opposed to the code that goes through your build pipeline. Build-time controls — pinned dependencies, software bills of materials, signed container images, scanners in CI — all describe the artefact you compiled. They say nothing about what a vendor’s content delivery network served to a particular customer at a particular moment. A modern checkout page typically loads scripts from several external origins: a tag manager, analytics tools, a chat widget, a fraud SDK, an experimentation tool. Each of those can load further scripts you never reviewed, at a depth you never approved. Because delivery happens per request, an attacker who compromises a vendor can serve a skimming payload to a small fraction of sessions, in one geography, only when a card field is present — and never to your monitoring or your QA environment. The compromised script runs as first-party JavaScript in your origin, with the same access to the DOM that your own code has. Nothing in your infrastructure is touched, which is precisely why server-side and build-time security cannot see the attack.

Q: What do PCI DSS requirements 6.4.3 and 11.6.1 actually require?

Requirement 6.4.3 is a script management control for payment pages: you must maintain an inventory of every script with a written business justification, confirm that each script is explicitly authorised, and assure the integrity of each script. Requirement 11.6.1 is a change and tamper detection control: you must be alerted to unauthorised modification of security-impacting HTTP headers and of the script content of payment pages, as received by the consumer browser. Both became effective on 31 March 2025 as part of the future-dated requirements in PCI DSS v4.0.1. The phrase “as received by the consumer browser” is the architecturally significant one, because it rules out checking only your repository, your build output or your own object storage. Satisfying it means observing the page as delivered — either through browser-native violation reporting to an endpoint you control, or through an out-of-band synthetic client that fetches and renders the real page and diffs it against an approved baseline. In practice, most organisations need both: the reporting endpoint builds the live inventory that 6.4.3 wants, and the synthetic client provides the independent drift detection that 11.6.1 wants.

Q: If our card fields are in a PSP iframe, are we exempt from 6.4.3 and 11.6.1?

No. Requirements 6.4.3 and 11.6.1 were removed from Self-Assessment Questionnaire A, but they were not removed from PCI DSS itself, and the Council’s guidance is explicit that merchants using iframes or embedded payment solutions must still ensure their payment page is protected against script-based attacks. That protection can be achieved directly, through a third party that deploys the protective techniques, or through third-party confirmation that its solution covers the merchant’s payment page. Beyond the compliance framing there is a security reason not to relax: an iframe boundary prevents the parent page from reading the fields inside the frame, but it does not prevent an attacker who has script execution in the parent page from doing damage. Such an attacker can overlay a pixel-perfect fake form on top of the iframe, capture keystrokes in the parent context, swap the iframe source, or manipulate the surrounding checkout flow. The payment service provider never sees any of this, because none of it happens inside their frame. Iframes and hosted fields genuinely reduce scope and are worth using — they simply do not remove either the obligation or the attack path.

Q: Why is an allowlist-based Content Security Policy considered ineffective?

Because an allowlist answers the wrong question. It asks where a script may be loaded from, and that answer is a list of external domains whose full contents you do not control and cannot audit. Popular content delivery networks host legacy AngularJS builds, JSONP endpoints, open redirects and user-uploaded files, any one of which can be used to execute attacker-chosen code from an allowed origin. Google’s large-scale study, published as “CSP Is Dead, Long Live CSP,” analysed 1,680,867 hosts carrying 26,011 unique policies and found that 94.68% of policies attempting to limit script execution were ineffective, 75.81% used script allowlists an attacker could bypass, and 99.34% of hosts with CSP had policies offering no benefit against cross-site scripting. The corrective is to change the question the policy asks. A nonce-based policy asks whether your own server stamped this specific script tag in this specific response — something only your server can do and an injected script cannot forge. Adding strict-dynamic propagates that trust to scripts loaded by already-trusted scripts, which is what makes a strict policy workable on a real site that uses a tag manager.

Q: What does a working strict CSP for a payment page look like?

A working policy is nonce-based rather than allowlist-based, and it closes the two side doors that otherwise defeat it. The shape is: script-src with a per-response random nonce plus strict-dynamic; object-src set to none; base-uri set to none; and a reporting directive pointing at an endpoint you own. The nonce must be cryptographically random and regenerated for every response — a value baked in at build time is simply an allowlist with extra steps, because an attacker who can read your HTML can read a static nonce. The strict-dynamic keyword allows scripts created by already-trusted scripts to run, which is what prevents the policy from breaking every third-party loader on the page. Setting object-src to none removes plugin-based execution paths, and base-uri to none prevents an injected base tag from re-pointing every relative script URL at an attacker-controlled host, which is a common and under-appreciated bypass. The practical constraint to plan for is caching: because the nonce changes per response, fully static HTML caching is incompatible with the policy, so you need an edge-generated nonce or a dynamic HTML layer. That is a rendering architecture decision, and it should be made before the security work starts rather than discovered halfway through.

Q: Where does Subresource Integrity help, and where does it not?

Subresource Integrity is excellent at one job: proving that a specific, version-pinned file is byte-identical to the one you approved. The browser computes a hash of the fetched resource using the strongest algorithm supplied, compares it to the integrity attribute, and on mismatch refuses to load the resource, returning a network error. Cross-origin resources additionally require the crossorigin attribute and permissive CORS headers, because integrity checking on opaque responses would leak information about their content. The limits are structural rather than incidental. SRI cannot cover a script that legitimately changes, which describes most tag managers, analytics loaders and vendor SDKs served from a stable URL with rolling contents — pinning those breaks your checkout on the vendor’s next release, after which someone removes the attribute during an incident and never restores it. SRI does not cover scripts injected dynamically by other JavaScript unless the injecting code sets the attribute itself, which vendor code will not do for you. It does not apply to inline script, and it says nothing about behaviour that changes after a valid load, so a script that passes its hash and then fetches instructions from a remote server is entirely SRI-clean. The honest architecture uses SRI for the pinnable tail and delivered-page monitoring for the mutable head.

Q: How do you build a script inventory that stays accurate?

By generating it from runtime evidence and reviewing the diff, rather than maintaining a document by hand. A hand-written spreadsheet is stale the first time a marketing team adds a pixel through a tag manager, and it will never again be a reliable statement of what runs on the payment page. Two sources feed a generated inventory. First, a Content Security Policy deployed in report-only mode against real production traffic, with violations sent to an endpoint you control: this surfaces the actual set of scripts that the real population of browsers, networks and geographies loads, including the ones your staging environment never sees. Second, an out-of-band headless browser that renders the real payment page on a schedule and records every script, its origin and its loader chain — which catches what violation reports alone cannot attribute. Both streams need normalisation and grouping before a human looks at them, because live traffic generates very large volumes of noise from browser extensions and injected network content, and an un-normalised firehose gets muted within a week. What reaches a person should be the diff against the approved baseline: new script, changed hash, changed header. The final piece is process — adding a script to checkout becomes a reviewed change with an owner, a written justification and an expiry date.

Q: Can tamper detection be implemented in JavaScript on the page itself?

It can be written that way, but it should not be trusted that way, because the detector shares an execution context with the thing it is trying to detect. Any JavaScript you ship on the payment page runs in the same origin and the same document as an attacker’s injected script. If the attacker executes first, or gains a reference to the objects your detector depends on, they can patch the functions it uses, suppress its network calls, feed it a clean view of the DOM, or simply prevent it from loading. Client-side integrity checking written in the compromised context is therefore evidence of intent rather than a control that holds under attack. The two mechanisms that do hold sit outside that context. The first is browser-native reporting: violations of the Content Security Policy are generated by the browser itself, not by your page code, and are sent to an endpoint you control, so the attacker cannot silently suppress them from within the page. The second is an out-of-band synthetic client — a headless browser running on your infrastructure that fetches and renders the delivered payment page on a regular cadence and diffs the script set, script hashes and security-impacting response headers against an approved baseline. Its honest weakness is that a sufficiently careful payload can fingerprint and hide from a prober, which is why it complements rather than replaces enforcement through a strict policy.

Satyam Kumar

Zurück zum Blog

security

The Payment Page Is Assembled in a Browser You Don’t Control

By Satyam KumarAugust 15, 202615 min read

client-side security content security policy subresource integrity pci dss 4.0.1 e-skimming magecart payment page security script integrity strict-dynamic csp nonce supply chain security web application security tamper detection appsec architecture checkout security 2026

The Payment Page Is Assembled in a Browser You Don’t Control

Frequently Asked Questions

Artikel teilen

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

KI & Cloud Architekt. Ich helfe Teams, Systeme zu bauen, die auf Millionen skalieren.

LinkedIn GitHub

The Payment Page Is Assembled in a Browser You Don’t Control

Frequently Asked Questions

Artikel teilen

Comments

Leave a comment