An online shop can process every order cleanly and still violate a mandatory security requirement without anyone noticing. Since 31 March 2025, two requirements of the payment card standard that were previously listed as recommendations have become mandatory: requirement 6.4.3 calls for an inventory of all scripts on the payment page, each one authorized and integrity-checked, and requirement 11.6.1 calls for at least weekly detection of unauthorized changes to those scripts and the page's HTTP headers (PCI Security Standards Council, PCI DSS 4.0.1). What is affected is not an exotic edge case but everyday reality: analytics tags, tag managers, chat widgets and consent scripts run in the customer's browser exactly where card data is entered. Because exploitation of vulnerabilities was recently the initial access vector in 20 percent of breaches, a rise of 34 percent over the prior year (Verizon DBIR 2025), and third-party involvement has doubled to 30 percent (Verizon DBIR 2025), the chain of foreign scripts moves into focus. Unlike the article on web skimming at the checkout, which describes the attack technique, this one is about the concrete compliance obligation and its proof: what PCI DSS 4.0.1 requires, what a clean inventory plus CSP, Subresource Integrity and weekly payment page monitoring looks like -- and why it remains an ongoing task.
What PCI DSS 4.0.1 Requires Since 31 March 2025
PCI DSS is the Payment Card Industry Data Security Standard -- the ruleset every operator that accepts card payments must comply with. The current version 4.0.1 is a limited revision of version 4.0 and, since its release, the authoritative basis. The two requirements at issue here were initially listed as future best practice in version 4.0 and became mandatory when the transition period ended on 31 March 2025 (PCI Security Standards Council, PCI DSS 4.0.1). They are now assessable: an assessor may require their implementation, and a missing script inventory or missing tamper detection is no longer an open point but a finding. The background is a measurable shift of attacks into the browser. Stolen credentials and exploited vulnerabilities lead the initial access vectors -- 88 percent of basic web application attacks used stolen credentials (Verizon DBIR 2025), and the human element was involved in 60 percent of breaches (Verizon DBIR 2025). A single compromised login is enough to write a foreign script into the payment page.
From Recommendation to Obligation
Which Scripts on the Payment Page Are Affected
The question of which scripts are actually affected regularly surprises in practice. Requirement 6.4.3 applies to every script loaded in the browser on the payment page -- your own and foreign, statically embedded and dynamically loaded. A typical shop embeds far more of them than is consciously documented: alongside your own code run analytics and marketing tags, a tag manager, a chat or support widget, a consent banner and the payment provider's scripts. Many of these in turn load further files, so the actually delivered script chain is longer than the list in the source. It is precisely these dynamically loaded dependencies that are the risk: if a provider changes a delivered file, the change runs along unchecked in the checkout.
Analytics and Marketing Tags
Counting pixels, conversion tags and analytics libraries often run on the payment page too. Each of them is a script subject to authorization and integrity under requirement 6.4.3.
Tag Manager
A tag manager loads further scripts dynamically and can change its content at any time -- without a deploy in the shop. That makes it powerful and, at the same time, a critical element in the inventory.
Chat and Support Widgets
Support chats embed external libraries that run along on every page. On the payment page they belong in the inventory, justified and integrity-monitored -- or removed from there.
Consent and Payment SDKs
Consent managers and the payment providers' SDKs load resources dynamically and sometimes switch their sources. They too fall under the inventory and tamper detection.
The first return of an inventory is therefore often reduction. A script that serves no purpose on the payment page does not belong there -- the smallest script chain is the easiest to monitor. A regular plugin and script audit keeps this chain lean and ensures that the list of approved scripts and the scripts actually delivered do not drift apart.
Requirement 6.4.3: the Script Inventory with Authorization
You can only secure what you know. Requirement 6.4.3 turns that into a rule and demands four things for every script on the payment page: an authorization, an integrity assurance, an entry in the inventory and a documented justification for why the script is loaded there (PCI Security Standards Council). The inventory is thus more than a list of filenames -- it is the link between which script, who approved it, how its integrity is verified and why it is needed. Only that link makes the inventory assessable.
- Capture all scripts: your own and external, statically embedded and dynamically loaded, including the scripts that tag managers, consent and payment widgets load in turn.
- Authorize each script: record who approved it and when -- the authorization is the core of the requirement, not the mere existence of the list.
- Assure integrity: bind each external script to a hash via Subresource Integrity and allow it only from approved sources through the Content Security Policy.
- Document the justification: for each script, record what purpose it serves on the payment page -- what cannot be justified gets removed.
- Version the inventory: with every deploy and every change to a foreign script the list is updated and re-approved so it reflects the actual state.
What an Assessable Inventory Contains
Requirement 11.6.1: Weekly Tamper Detection
An inventory describes the target state. Requirement 11.6.1 additionally demands checking the actual state against it continuously: a mechanism that detects unauthorized changes to the scripts and the security-relevant HTTP headers of the payment page and alerts the responsible personnel -- and that runs at least once a week (PCI Security Standards Council). In practice this means regularly comparing the state of the page actually delivered in the browser against the approved reference state: the list of loaded scripts, the content hashes and the headers such as the Content Security Policy. Every deviation -- a new script, a changed file, a tampered header -- triggers an alert.
Seven Days Is the Minimum, Not the Goal
What matters is what tamper detection has to achieve and what individual browser mechanisms do not cover on their own. The standard's supplementary information document on payment page security explicitly states that Content Security Policy and Subresource Integrity do not fully meet requirement 11.6.1 (PCI Security Standards Council, Payment Page Security and Preventing E-Skimming). Both secure the integrity of individual scripts but reliably detect neither the deletion of a script nor behavioral manipulation nor changes to the HTTP headers. That is why resilient detection combines several techniques -- for example observing the delivered page in the browser, comparing content hashes and checking the headers against the reference state.
CSP and SRI: Necessary, but Not Sufficient
That names the most common misconception: that a well-maintained Content Security Policy and Subresource Integrity already cover the new requirements. Both are indispensable and carry the lion's share of the integrity assurance under 6.4.3 -- but for the evidence under 11.6.1 they are not enough. To make matters worse, CSP is often watered down in practice: only around 22 percent of all hosts serve a Content Security Policy at all (HTTP Archive Web Almanac 2025), and over 92 percent of sites with a CSP allow unsafe-inline and thereby largely cancel a central protection (HTTP Archive Web Almanac 2025). The effect of the mechanisms therefore depends not only on their existence but on their configuration and upkeep.
| Mechanism | What it secures | Limit for the evidence |
|---|---|---|
| Content Security Policy | Restricts script sources and target domains for data | Does not detect deleted scripts or behavioral changes |
| Subresource Integrity | Binds an external script to a content hash | Only works for statically versioned files |
| Webpage monitoring | Observes the delivered page for new or changed scripts | Requires a maintained reference state |
| Inventory and authorization | Documents the purpose and approval of each script | Only holds up if carried along with every change |
What a restrictive Content Security Policy and its upkeep look like in detail is covered by the article on HTTP security headers with CSP and HSTS; how injected scripts at the checkout concretely lead to data leakage is shown by the article on web skimming at the checkout. For the PCI evidence both come together: the technical protection through CSP and SRI and the ongoing, logged monitoring that makes a deviation visible and provable. This pairing of control and evidence PCI DSS 4.0.1 shares with other frameworks -- for example the NIS2 obligations for online shops, where too it is not just the measure but its proof that counts.
What the Evidence for PCI DSS 4.0.1 Looks Like
The real difference between these requirements and many other security measures lies in the word evidence. It is not enough to keep an inventory and run monitoring -- both must be provable. An assessor or an internal audit asks not only whether tamper detection exists, but wants to see that it ran at the required cadence, which scripts were approved and how a deviation was handled. This evidence does not arise retroactively; it must accrue continuously. That is why we log every relevant change: the approval of a script, the adjustment of a CSP rule, the alert on a detected deviation and the response that follows. The cost of an omission is real -- a data breach is on average identified and contained only after 241 days (IBM Cost of a Data Breach 2025), time in which an unnoticed foreign script reads along undisturbed.
- A versioned script inventory with authorization, integrity evidence and justification for each script (requirement 6.4.3).
- A log of the check runs that documents the at-least-weekly cadence of the tamper detection (requirement 11.6.1).
- A traceable change history of the payment page scripts and the security-relevant HTTP headers.
- An alert and response log that shows how a detected deviation was handled and when it was resolved.
- A documented justification for the chosen check interval if it deviates from the weekly default cadence.
With the new PCI requirements, what decides is not whether a shop has its scripts under control, but whether it can prove it. Whoever only assembles the evidence at the assessment does not have it.
Why This Is Ongoing Maintenance, Not a One-Off
All of this explains why meeting these requirements is not a one-off project. A shop changes constantly: themes are updated, extensions are added, a payment provider switches its SDK, a tag manager loads a new script. Each of these changes can bring a new script into the payment page or alter an existing one -- and thereby let the inventory age and trigger a tamper detection alert that needs to be assessed and documented. The standard's supplementary information document also describes attack patterns such as the double-entry fraud, in which customers are prompted via an upstream false form to enter their card data a second time (PCI Security Standards Council, Payment Page Security and Preventing E-Skimming) -- such variants arise precisely in the gaps that open up between two one-off checks.
That is why we run the script inventory, CSP and SRI upkeep and the weekly tamper detection as a fixed part of ongoing security update care and of payment page monitoring -- closely interlocked with patch and CVE management, which closes the most common entry points, and with Shopware maintenance in day-to-day operation. Where consent and analytics scripts are involved, this reaches into the GDPR updates; where the stability of the payment page under load is at stake, into checkout and transaction monitoring and the load test for peak traffic. The average total cost of a data breach was recently 4.44 million US dollars worldwide (IBM Cost of a Data Breach 2025); for smaller shops the figure is lower, yet lost sales, possible sanctions and damaged trust remain. As part of an SLA maintenance contract and our full managed maintenance services, the PCI obligation becomes a calm, traceable process with evidence -- instead of a task that only surfaces at the next assessment.