Third-Party JavaScript Management Guide

Most organisations cannot say with confidence which third-party scripts run on their checkout page today, who added them, or what data they can read. Analytics, advertising, chat, consent, A/B testing and fraud scripts arrive through developers, tag managers and other scripts, and each one runs with the same access to the page as your own code. This guide is the operating model for controlling that estate: how to build and keep a script inventory, how to govern tag managers, which technical controls fit which kind of script, how to meet PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 on payment pages, and what to monitor. It is for application security leads, front-end platform teams, marketing technology owners and PCI programme managers. For the browser-side threat model see the Client-Side Security Guide; this page focuses on governance and operations.

Key takeaways

The inventory is the control. Without a current list of every script, its source, owner, purpose and data access, no other client-side control can be verified, and PCI DSS 6.4.3 cannot be evidenced.
Tag managers are a deployment pipeline. Anyone with publish rights can push JavaScript to production without a code review, so publish access, custom HTML tags and change approval need the same rigour as CI/CD.
Match the control to the script. Static libraries get pinning and SRI or self-hosting; dynamic vendor scripts get isolation, CSP limits and monitoring; scripts with no clear purpose get removed.
Keep payment pages minimal. The cheapest way to pass 6.4.3 and 11.6.1 is to have few scripts on payment pages, ideally with card entry in a payment service provider iframe.
Detection must watch what the browser receives. Requirement 11.6.1 targets script contents and security headers as received by the consumer's browser, not what is in your repository.

Where third-party JavaScript comes from

The OWASP Third Party JavaScript Management Cheat Sheet identifies three risks: loss of control over changes to the client application, execution of arbitrary code in users' browsers, and disclosure of user data to third parties. It also describes the deployment patterns, which matter because each has a different owner and change path.

Deployment pattern	Who changes it	Visibility	Main risk
Vendor code pasted inline into the page	Developers, via code review	High: code is in your repository	Unreviewed code and vulnerabilities copied in once and forgotten
Script tag pointing at the vendor's host	The vendor, at any time	Low: content changes without a release	Vendor host compromise or silent update reaches every visitor
Tag manager container loading vendor tags	Marketing or analytics users in the tag manager interface	Low unless the container is reviewed	Production JavaScript published outside engineering change control
Fourth-party scripts loaded by a vendor script	The vendor's suppliers	Very low	Code from organisations you have no contract with
Server-side collection or data layer feeding vendors	Your developers	High	Lower: browser execution of vendor code is reduced, though tags still in the page remain in scope

Building and maintaining the script inventory

A spreadsheet produced once for an audit is not an inventory. It has to be generated from what pages actually load and reconciled continuously.

Discover: crawl in-scope pages with a headless browser in several states (logged out, logged in, basket, payment step, consent accepted and declined) and record every script URL, including scripts injected by other scripts. Add CSP report-only data from real users to catch scripts that crawlers miss.
Record fields: script URL and host, loading path (direct, tag manager, fourth party), version or hash, business owner, technical owner, purpose, data it can access, pages it runs on, contract or data processing agreement reference, and written business or technical justification.
Approve: each entry needs a named approver. That record is the "method to confirm that each script is authorized" PCI DSS 6.4.3 asks for.
Reconcile: rerun discovery on a schedule and on every release, and diff against the approved list. Anything new and unapproved is either added through the approval process or removed.
Retire: review entries quarterly; scripts for ended campaigns and replaced vendors are the most common unneeded code on payment pages.

Governing tag managers

A tag manager lets non-developers publish code to production. That is its purpose, and it is why it must be governed as a deployment system. The OWASP cheat sheet recommends restricting the tag types deployed on a site, for example disabling custom HTML tags and custom JavaScript, verifying the tag manager's access controls, and noting that a data layer is not a sandbox because containers can still execute custom code.

Role separation: Google Tag Manager, for example, has container permissions of Read, Edit, Approve and Publish. Keep Publish to a small group, require a second person to approve versions for containers that run on sensitive pages, and remove leavers promptly.
Account security: enforce single sign-on and phishing-resistant MFA for tag manager accounts. A compromised publisher account is a direct route to injecting a skimmer.
Restrict tag types in code: Google Tag Manager supports gtm.allowlist and gtm.blocklist pushed to the data layer before tags fire; blocking the customScripts class (alias html) or nonGoogleScripts stops arbitrary JavaScript even if someone configures it. Google recommends custom templates with template policies as the stronger option. Equivalent controls exist in other tag managers; check vendor documentation.
Separate containers for sensitive pages: use a dedicated, minimal container (or none) on login and payment pages, so marketing changes to the main container cannot reach them.
Version review: export container versions and review diffs as you would code; keep the history as audit evidence.
Data layer discipline: expose only the values vendors need through a host-defined data layer, and never let tags read URL parameters or form fields directly.

Choosing technical controls by script type

Script type	Primary control	Supporting controls
Static open source library	Self-host from your build, or pin version plus SRI	Dependency scanning, lockfile. See the Subresource Integrity Guide.
Vendor SDK with versioned URLs	Pin version plus SRI	Contract clause requiring notice of changes and published hashes
Vendor SDK that updates in place	Run it in a sandboxed iframe on a separate origin, or move collection server-side	CSP `script-src` and `connect-src` allowlists, behavioural monitoring
Tag manager container	Publish controls and tag type restrictions	Version review, separate container for sensitive pages
Card entry fields	Payment service provider hosted iframe or redirect	Monitor the parent page that embeds it
Scripts with no owner or purpose	Remove	Block via CSP until removal is deployed

Content Security Policy: a nonce or hash based script-src stops unapproved scripts executing, and connect-src, form-action and img-src limits restrict where stolen data can be sent. Start with Content-Security-Policy-Report-Only. See the Content Security Policy Guide.
Iframe isolation: the OWASP cheat sheet describes placing vendor code in an iframe on a different domain as a "jail", communicating with postMessage and restricting it with the sandbox attribute. Avoid combining allow-scripts with allow-same-origin for same-origin frames, which lets the frame remove its own sandbox.
Integrity enforcement: the Integrity-Policy header can block scripts loaded without integrity metadata on pages where every script should be hashed.
Server-side collection: for analytics that do not need to run in the browser, send a fixed event schema to a collector you control and forward to vendors from the server.

Meeting PCI DSS 6.4.3 and 11.6.1

PCI DSS v4.0.1 requirement 6.4.3 requires that all payment page scripts loaded and executed in the consumer's browser are managed with a method to confirm each script is authorised, a method to assure the integrity of each script, and an inventory of all scripts with written business or technical justification. Requirement 11.6.1 requires a change and tamper detection mechanism that alerts personnel to unauthorised modification of security-impacting HTTP headers and script contents of payment pages as received by the consumer's browser, evaluated at least weekly or at a frequency set by a targeted risk analysis. Both became mandatory on 31 March 2025.

In January 2025 the PCI Security Standards Council removed 6.4.3 and 11.6.1 (and the related targeted risk analysis requirement 12.3.1) from SAQ A, and added an eligibility criterion that the merchant confirms its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The Council stated that the underlying requirements are not removed or weakened. Merchants using SAQ A still need a defensible basis for that confirmation, which in practice means knowing what scripts run on the page that embeds the payment iframe. See the PCI DSS for E-commerce Payment Page Scripts Guide.

Requirement element	Evidence an assessor can test	Typical source
6.4.3 authorisation	Approval record per script with approver and date	Inventory tool or change tickets
6.4.3 integrity	SRI hashes, CSP hash or nonce policy, or tamper monitoring output	Source control, response headers, monitoring reports
6.4.3 inventory and justification	Current list matching what the page loads, each with a reason	Discovery crawl reconciled with approved list
11.6.1 detection	Alerts on script and header changes as received by the browser, with review records at the required frequency	Client-side monitoring or synthetic browser checks
11.6.1 response	Tickets showing alerts were triaged	SOC or incident queue

Implementation plan

Scope: list payment, login, account and other high-value pages. Start with payment pages because they carry regulatory deadlines.
Discover and baseline: run the crawl, deploy CSP in report-only mode to collect real-user data for two to four weeks, and build the first inventory.
Reduce: remove scripts with no owner, move card entry to a hosted iframe where possible, and create a minimal container for payment pages.
Harden tag managers: cut Publish access, enforce SSO and MFA, add approval for sensitive containers, and block custom script tags on payment pages.
Apply controls by type: self-host or hash static files, isolate dynamic vendors, and write a CSP for each page group.
Enforce in rings: enforce CSP on one low-traffic page group first, watch reports and conversion metrics, then extend. Rollback is reverting the header to report-only, not deleting the policy.
Monitor: stand up 11.6.1 monitoring, route alerts to a queue with an owner, and document the review frequency.
Operate: wire the approval step into the change process for developers and the tag manager, and reconcile the inventory on every release.

Small versus large organisations: a small merchant can often meet the intent with a hosted payment page or iframe, no tag manager on the payment step, a strict CSP and a weekly synthetic browser check. A large retailer with many brands and agencies needs an inventory tool fed by continuous discovery, per-brand tag manager governance, contract clauses for vendor script changes and a monitored alert queue.

Detection and measurement

New script sources: alert on any script host or URL on a sensitive page not in the approved inventory.
Content changes: hash scripts as received by a real browser and alert when an approved script's content changes without a matching change record.
Header changes: alert when CSP, Integrity-Policy or other security headers change or disappear on payment pages.
Exfiltration attempts: CSP connect-src and form-action violation reports pointing to unknown hosts are high-signal events.
Tag manager audit: review publish events and user changes in the tag manager, especially publishes outside business hours or by new users.

Metrics:

Percentage of scripts on in-scope pages that are in the approved inventory (target 100 percent).
Number of scripts on payment pages, trended down over time.
Median time from detection of an unapproved script or content change to triage.
Number of users with tag manager Publish rights, and percentage with MFA.
Percentage of in-scope pages with an enforcing CSP.
Inventory entries reviewed within the last quarter.

Framework mapping

Framework	Reference	Relevance
PCI DSS v4.0.1	6.4.3, 11.6.1, 12.3.1	Payment page script management, tamper detection, targeted risk analysis for frequency
OWASP ASVS 5.0	V3.4.3, V3.6.1	CSP baseline; external assets only if static, versioned and SRI-protected, or a documented decision
NIST SP 800-53 Rev. 5	CM-8, SA-9, SI-7, SI-4	Component inventory, external services, integrity, monitoring
NIST CSF 2.0	ID.AM-02, GV.SC-07, DE.CM-09	Software inventory, supplier risk, monitoring of software and runtime environments
MITRE ATT&CK	T1195.002 Compromise Software Supply Chain; T1185 Browser Session Hijacking; T1189 Drive-by Compromise	Compromised vendor scripts and in-page code that steals sessions or data

Common failure patterns

Inventory built once: the list is accurate on audit day and wrong a month later because tag manager changes never reach it.
Floating CDN versions: sites that loaded the player from public CDNs with the latest tag served a wallet drainer during the Lottie Player npm compromise without changing anything themselves. Pin versions and record them in the inventory.
Marketing container on the payment page: a single container shared across the site lets any campaign tag reach checkout.
Monitoring the repository, not the browser: vendor and fourth-party scripts never appear in source control, so a code scan cannot meet 11.6.1.
Alerts with no owner: tamper detection that emails a shared mailbox nobody reads produces evidence of failure, not control.
Treating SAQ A as "no script work": the eligibility criterion still requires the merchant to be able to show its site is not susceptible to script attacks.

Where identity fits

Three identities decide what JavaScript reaches your users: tag manager publishers, the vendor accounts and tokens that publish SDKs, and the CI or deploy roles that write to your asset storage. Bring tag manager accounts into your identity governance reviews, and treat CDN, bucket and package publishing credentials as privileged non-human identities. See the npm Tokens Security Guide.

Practitioner checklist

Generate the script inventory from real browser loads on every in-scope page and reconcile it on each release.
Record owner, purpose, data access, justification and approver for every script.
Limit tag manager Publish rights, enforce SSO and MFA, and require approval for sensitive containers.
Block custom JavaScript tags on payment pages using tag manager restrictions or a separate container.
Self-host or pin and hash static scripts; isolate dynamic vendor scripts in sandboxed iframes.
Deploy CSP in report-only mode, then enforce with nonces or hashes and restrictive connect-src and form-action.
Monitor script contents and security headers as received by the browser, with a named alert owner.
Move card entry to a payment service provider iframe or redirect where possible.
Add contract terms requiring vendors to give notice of script changes.
Rehearse the response with the Web Skimming Incident Playbook.

Third-Party JavaScript Management Guide: Tag Managers, Script Inventories and PCI DSS 6.4.3