Client-Side Script Protection Buyer’s Guide: Choosing Tools for PCI DSS 6.4.3 and 11.6.1

Web skimmers run in the customer's browser, where server-side scanners, WAFs and code review cannot see them, so the only reliable place to catch a modified payment page is the page as the browser actually receives it. Since 31 March 2025, PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1 have made script authorisation, integrity, inventory and change detection on payment pages mandatory, and a market of client-side script protection tools has grown around them. This vendor-neutral buyer's guide explains what the category does, which detection approaches the standard itself recognises, how to evaluate tools against your page architecture and how to prove them before you buy. It is for e-commerce security leads, PCI programme owners and web platform teams. The control design is covered in the Client-Side Security Guide and the requirement detail in the PCI DSS for E-commerce Payment Page Scripts Guide.

Key takeaways

• Two requirements, two jobs. 6.4.3 is about managing scripts (authorise, assure integrity, keep a justified inventory); 11.6.1 is about detecting unauthorised changes to scripts and security-impacting HTTP headers as received by the browser, at least weekly or at a risk-analysed frequency.
• The standard lists the approaches. PCI DSS guidance names CSP violation reporting, synthetic user monitoring, embedded tamper-detection scripts and reverse proxies or CDNs, and says no single one is necessarily a full mechanism.
• Architecture decides scope. Scripts inside a payment provider's embedded iframe are the provider's responsibility, but scripts on your page that hosts the iframe are yours.
• Evidence is the deliverable. A tool is only as good as the inventory, justifications, alerts and response records it gives your assessor.
• Skimmers arrive through identities. CDN keys, CI tokens and CMS admin accounts are how scripts get changed, so pair browser-side detection with tight control of who can publish front-end assets.

What the category does

Client-side script protection tools discover the scripts that run on your web pages, record what each one is and does, help you authorise and lock down the permitted set, and alert when what the browser receives differs from what you approved. Requirement 6.4.3 in PCI DSS v4.0.1 requires that all payment page scripts loaded and executed in the consumer's browser are managed so that a method confirms each script is authorised, a method assures the integrity of each script, and an inventory of all scripts is maintained with written business or technical justification. Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts personnel to unauthorised 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.

The standard also gives Subresource Integrity, CSP and proprietary script or tamper-detection systems as examples for assuring script integrity under 6.4.3. Most commercial tools combine two or more of these approaches; the evaluation is about which combination fits your pages.

When you need it

• You run your own payment page, or a page that embeds a payment provider's iframe, and are assessed against PCI DSS v4.0.1. Both 6.4.3 and 11.6.1 apply to the page that hosts the iframe.
• You validate with SAQ A: on 30 January 2025 the PCI SSC removed 6.4.3, 11.6.1 and 12.3.1 from SAQ A but added an eligibility criterion that merchants confirm their site is not susceptible to attacks from scripts that could affect their e-commerce systems. Many merchants use a tool to support that confirmation.
• Your pages carry many third-party scripts: analytics, A/B testing, chat, consent, tag managers and advertising, which can load further scripts you never reviewed. See the Third-Party JavaScript Management Guide.
• Beyond payments: login, account and checkout pages where scripts can read credentials, session tokens or personal data.

When you may not: a merchant that fully redirects to a payment provider for the whole payment page, with no scripts able to affect it, may meet its needs with good CSP, SRI on static assets and the provider's evidence. Confirm your integration type with your assessor before buying.

Must-have capabilities

• Automatic script inventory: every first, third and fourth-party script on in-scope pages, with source, hash, version history, and what loads it (including tag managers).
• Authorisation workflow: approve or reject each script with a recorded business or technical justification and approver, matching the 6.4.3 inventory element. PCI guidance allows authorisation as soon as possible after a change where prior approval is impractical, so the workflow must handle both.
• Integrity enforcement: generate and maintain CSP policies and SRI hashes, or enforce an allowlist at runtime, and show which method covers each script.
• Header monitoring: detect changes to security-impacting headers such as Content-Security-Policy, not only script content.
• Behavioural detection: flag scripts that read payment or credential fields, add event listeners on forms, or send data to new destinations.
• Alerting and response integration: alerts to your SIEM, ticketing and incident response process, so 12.10.5 response procedures have something to act on.
• Configurable frequency: at least weekly evaluation, or continuous, with the frequency and rationale recorded for a targeted risk analysis under 12.3.1 if you choose another interval.
• Assessor-ready evidence: exportable inventory, justification records, alert history and configuration snapshots.

Evaluation criteria

Questions to ask vendors

1. Which of the approaches named in PCI DSS guidance (CSP reporting, synthetic monitoring, embedded script, proxy or CDN) does the product use, and what does each one miss?
2. How do you detect a skimmer that only activates for certain countries, devices, referrers or real payment sessions?
3. Do you monitor security-impacting HTTP headers as well as script content, and which headers?
4. How is the inventory built, and how do you attribute scripts loaded by tag managers or by other scripts?
5. What exactly does your in-page script collect, does it ever see form field values, and where is that data stored?
6. How is your own script delivered and integrity-protected on our page, and what happens to our checkout if your service is unavailable?
7. How do you reduce alert noise from legitimate third-party updates, and can approvals be automated for trusted vendors with recorded justification?
8. What evidence do you produce for 6.4.3, 11.6.1 and 12.3.1, and have assessors accepted it?
9. How do alerts reach our SIEM and incident process, and what is your mean time to alert in tests?
10. Which admin roles exist in your console, and is MFA enforced for every user who can approve scripts?

Red flags

• Claims that a single mechanism fully meets 11.6.1; the standard says no single listed mechanism is necessarily a full detection and reporting mechanism.
• Monitoring that only scans your origin servers or repositories, not what the browser receives.
• An in-page script that captures form contents or payment data.
• No header monitoring, or no record of who approved each script and why.
• Vendor script delivered without integrity protection, or with no fail-safe if the vendor is down.
• Evidence exports that require manual assembly before an assessment.

Deployment and integration

1. Map in-scope pages: every page that is a payment page or hosts a provider's iframe, plus login and account pages if you extend scope.
2. Discover in observe mode: run inventory and monitoring without blocking for two to four weeks to capture normal script churn.
3. Authorise and justify: review every script with its owner, remove what is not needed and record justifications.
4. Enforce in rings: apply CSP in report-only mode first, then enforce on a low-traffic page, then all payment pages. Keep a rollback path that reverts to the last known-good policy without removing monitoring.
5. Integrate: send alerts to the SIEM and ticketing, and add skimming scenarios to incident response playbooks. See the Web Skimming Incident Playbook.
6. Close the publishing path: restrict who and what can change front-end assets.

Where identity fits: skimmers reach payment pages through the credentials that can publish scripts. In the AI Agent Retail Card Theft Campaign, one route was an AWS access key with write permissions to the bucket behind a retailer's CDN, so the store served the skimmer from its own domain; other routes included appended JavaScript, a Kubernetes initContainer and a cron job that re-injected the skimmer every two minutes after redeploys. Browser-side monitoring catches the result; least-privilege CDN keys, CI tokens and CMS admin accounts reduce the chance. See the Content Security Policy Guide and the Subresource Integrity (SRI) Guide.

Pitfalls

• Buying for compliance only: a weekly synthetic scan may satisfy the letter of 11.6.1 but miss a skimmer that runs for six days.
• Ignoring the iframe host page: assuming the payment provider covers everything when your page around the iframe carries analytics and tag manager scripts.
• Approval fatigue: hundreds of low-value alerts lead teams to auto-approve, which defeats 6.4.3.
• Adding risk with the tool: an unprotected vendor script on the payment page becomes a new supply chain dependency.
• No response plan: alerts arrive but nobody owns the decision to pull a script or take checkout offline.

Proof of concept

1. Clone a payment page to staging with its real third-party scripts and tag manager.
2. Let each tool build an inventory and compare it with a manual review in browser developer tools.
3. Introduce controlled, harmless changes: modify an allowed script, add a new script through the tag manager, add a script that reads a test form field and sends it to a test endpoint, and change the CSP header.
4. Measure for each change whether it was detected, how long the alert took and how clear it was.
5. Measure page performance impact and review what data the tool collected.
6. Export the evidence pack and walk through it with your QSA or internal assessor.
7. Remove the tool and confirm the page still works and no residue remains.

Buyer checklist

• In-scope pages and integration type (embedded iframe, redirect, own page) confirmed with the assessor.
• Approaches used by the tool mapped to the four mechanisms in PCI DSS guidance, with gaps covered.
• Script inventory with justification and approver for every script.
• Header monitoring confirmed, including Content-Security-Policy.
• Seeded change test passed with measured time to alert.
• No collection of payment or form data; data handling agreed.
• Vendor script integrity and fail-safe behaviour verified.
• Alerts integrated with SIEM, ticketing and the skimming response playbook.
• Front-end publishing credentials (CDN, CI, CMS, tag manager) reviewed for least privilege.

Framework mapping

Standards and references

• PCI SSC: PCI DSS v4.0.1 Requirements and Testing Procedures
• PCI SSC: Payment Page Security and Preventing E-Skimming information supplement
• PCI SSC: Important updates for merchants validating to SAQ A
• MDN: Content-Security-Policy-Report-Only
• MDN: Subresource Integrity
• MITRE ATT&CK: JavaScript (T1059.007)
• NIST: SP 800-53 Rev. 5

How NHI Mgmt Group can help

We provide independent requirements and evaluation support for application security, PCI DSS and identity programmes. Browse vendors in our products directory or contact us.

Related NHI Mgmt Group resources: Client-Side Security Guide · PCI DSS for E-commerce Payment Page Scripts Guide · Third-Party JavaScript Management Guide · Web Skimming Incident Playbook