Script monitor
Payment page scripts (PCI DSS 6.4.3 and 11.6.1 helper)
How ChargeWarden inventories scripts on the WooCommerce checkout and pay for order pages, records justifications, detects changes, exports evidence, and what it does not cover.
Last updated by the PluginLoom team
ChargeWarden > Payment page scripts lists every script that runs on your checkout and pay for order pages, asks you to authorize each with a written reason, and alerts you when a new script appears or an authorized one changes.
It helps you keep the records described in PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1. It does not make your store compliant and it is not an assessment.
What do 6.4.3 and 11.6.1 ask for?#
The PCI Security Standards Council says requirements 6.4.3 and 11.6.1 "become effective as of 31 March 2025" (PCI SSC blog, 30 January 2025 (opens in a new tab)). In summary:
- 6.4.3: every payment page script loaded in the shopper's browser is authorized, its integrity is assured, and there is an inventory with a written justification for each.
- 11.6.1: a change and tamper detection mechanism alerts staff to unauthorized changes to the security-impacting HTTP headers and script contents of payment pages, at least weekly or at the frequency your targeted risk analysis sets.
Read the exact wording in the PCI DSS v4.0.1 standard from the PCI SSC document library before you rely on it; we summarise it here.
How do SAQ A merchants fit in?#
The January 2025 revision of SAQ A removed 6.4.3 and 11.6.1 from the questionnaire and added an eligibility criterion that the merchant has "confirmed their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)" (same PCI SSC post). PCI SSC FAQ 1588 (opens in a new tab) (February 2025) says this applies to merchants whose page embeds a payment provider's form or iframe, not to full redirects, and gives two ways to meet it:
- use techniques such as those in 6.4.3 and 11.6.1, deployed by the merchant or a third party, or
- get confirmation from your PCI DSS compliant payment provider that its embedded form, used as instructed, includes protection against script attacks.
Ask your acquirer which it expects. ChargeWarden helps with the first route.
Where does the inventory come from?#
| Source | What it sees |
|---|---|
| Server | Every script WordPress enqueued when it printed the checkout or pay for order page. Local files are hashed from disk. Written at most once an hour unless the list changes |
| Browser | A small reporter on payment pages lists the scripts the shopper's browser actually has, including scripts a tag manager injects, for one minute after load. Inline scripts are reported as a hash of their code |
| Daily scan | Re-hashes every inventoried script (local files from disk, remote files by download) and records the checkout page's security headers |
| CSP reports (optional) | A Content-Security-Policy-Report-Only header makes browsers report scripts from origins you have not authorized. It never blocks anything |
Inline scripts that WordPress prints with an id (for example wc-checkout-js-extra) are tracked by that id, because their content holds per-visitor values. Other inline scripts are keyed by a hash of their code with nonces and timestamps normalised.
How do I authorize a script?#
Open the script's Authorize panel, write why it is needed on the payment page (at least 10 characters), choose the integrity check and save. The justification, your name and the time are stored.
| Integrity check | Use for |
|---|---|
| Alert when the content changes | Your theme and plugin files, which change only when you update |
| Address only | Provider scripts that update on their own schedule, such as js.stripe.com/v3. Their content is still hashed and logged |
An authorized script whose content changes moves to Changed and you get an email. Check it and authorize it again, or remove it.
What evidence can I export?#
Download evidence CSV includes the purpose statement, what is not covered, the last scan with the security headers, every script with status, hashes, SRI digest, justification and who authorized it, and the full change log.
What does it not cover?#
- It does not make your store PCI DSS compliant, and it is not a QSA assessment.
- It cannot see scripts inside a payment provider's iframe or hosted page (for example card fields served by Stripe, PayPal or WooPayments). The provider is responsible for those.
- It does not block scripts. It records, compares and alerts. The optional CSP header is report-only.
- The browser reporter only runs in browsers that load it. A skimmer that targets some visitors only, or removes the reporter, can be missed; the server inventory and daily scan reduce that gap but do not remove it.
- Scripts in address-only mode are checked by address, not content.
- Remote scripts are downloaded by your server, which can receive different content than a shopper's browser.
- It does not check HTML, CSS or images, only scripts and a set of security headers.
Was this page helpful?