Home
/
Use cases
/
Third-party script monitoring

Third-party script monitoring, including the scripts you never added

You approved a vendor. The vendor loaded two more. All three executed on your page, and the browser treats them identically. Here is what monitoring third-party scripts actually involves.
Start for free
Talk to an expert
TL;DR
Third-party script monitoring
THE SET IS A TREE, NOT A LIST
Vendors load vendors. The last script in a chain is often a company you have never heard of, and it executed with the same privileges as your own code.
FOUR THINGS TO MONITOR
Identity and load chain, payload integrity, runtime behaviour, and change over time. Most tools cover the first and stop.
MAKE IT A WEEKLY QUEUE
A review that surfaces only what changed takes ten minutes. An annual report of everything takes a week and gets skipped.
Short on time? Approving a vendor is not the same as approving a script, and 6.4.3 applies to the script.
ON THIS PAGE

What is third-party script monitoring?

Third-party script monitoring is the practice of recording every externally sourced script that executes on your pages, verifying that each one is authorised and unchanged, observing what it does at runtime, and alerting when any of that changes. It exists because a modern page runs code from companies you have a contract with, companies you do not, and companies you have never heard of, all with the same privileges as your own JavaScript. A script from an analytics vendor can read your payment form just as easily as your checkout code can. On payment pages this stopped being optional in March 2025, when PCI DSS requirement 6.4.3 became mandatory.

First party, third party, and the ones nobody counted

Teams usually know their third parties. The gap is what those third parties load. A tag manager is a mechanism for loading other people's code, and the vendors it loads frequently load their own, so the set of code executing on your page is a tree rather than a list.
Load chain from pay.northwind.com: each vendor the payment page loads and the vendors those load in turn, with 3 hops to review
You approve a vendor, the vendor loads its own vendors. 6.4.3 applies to every script that executes, not only the ones you added yourself.
The practical consequence: approving a vendor is not the same as approving a script. You approved a relationship with a company. What executed was a chain, and the last link is often somebody you have never heard of. PCI DSS 6.4.3 makes no distinction between the script you added and the script your vendor's vendor added, because the browser makes no distinction either.

What monitoring a third-party script actually means

01
Identity
Where it loaded from, what loaded it, and when it first appeared. The load chain is the part that answers why a script you never approved is on the page.
02
Integrity
Whether the payload matches what you approved. A vendor can change file contents without changing the URL, and an origin allowlist will not notice.
03
Behaviour
What the script does once running: which DOM elements it touches, whether it reads form fields, and where it sends data.
04
Change over time
When any of the above moved. A script that was well-behaved for six months and changed last Tuesday is the interesting case.

Turning monitoring into a vendor review that happens

Most vendor reviews fail for organizational reasons rather than technical ones: the list is out of date, nobody owns it, and the review happens once a year under assessment pressure. Monitoring helps only if it produces a small, regular queue rather than a large annual report.
The useful shape is a weekly prompt containing only what changed: new scripts, new destinations, and approved scripts whose payload moved. Everything stable stays quiet. A vendor review that takes ten minutes a week is a vendor review that actually happens.
Unlimited scripts, vendors and domains on every plan. You are only metered on page views.
Start for free
See pricing
The same visibility answers questions from outside the security team. Which scripts are sending data to a destination you did not expect. Whether a tag that was supposed to be removed after a campaign is actually gone. Both are answered from the same inventory.
Related
JavaScript monitoring
Client-side security
Vendors and load chains
The DebugBear compromise

Frequently asked questions

Read the FAQ
Yes, and it is consistently the noisiest thing we see. The trap is that a container looks trustworthy because of who publishes it: you see Google Tag Manager and assume it is fine. An attacker does not need your container, they inject through a different container loaded as a sub-request, so the origin still reads as Google. What matters is the behaviour of what the container loaded, not the name on it.
Meaningfully different. A tag manager shows the tags configured in it. It does not show what those tags loaded afterwards, and it does not show anything added outside the container, which includes anything an attacker injected. The container is a list of intentions, not a record of what ran.
Sometimes. PCI only requires it on payment pages. Many teams extend it to login and account pages because the same class of script can harvest credentials or personal data.
Useful terms: a third party is a vendor whose script you added. A fourth party is a script that your vendor's script loaded. Nth party is the general case of a chain of arbitrary depth. They matter because you have no contract with them, often no visibility, and full exposure.
Yes, marginally, like any tag, and it is designed not to be felt. The tag is small, runs first in the head so it sees every script after it, and is fail-open, so if our service is unavailable your page still renders. The heavy analysis of each script happens off the page rather than in your visitor's browser.
Yes. Monitor-only mode produces the same evidence, including a record of what would have been blocked and on which pages, with nothing stopped. Most teams run this way for a few weeks while the inventory settles.
More than the team expects, and the number itself is less useful than the chain. The consistent finding when teams first look is not the count but the depth: scripts two and three links away from anything anyone approved. We would rather you measure your own than quote an industry average at you.
No, you choose the pages. Scope is defined by URL pattern, and only pages matching those patterns are monitored and counted. For PCI work that is usually the payment pages on their own. For broader third-party risk, teams widen it to whichever pages carry the most vendor tags.
Recording every externally sourced script that runs on your pages, checking that each one is authorised and unchanged, seeing what it does, and alerting when that changes. It is the third-party part of script monitoring.
A tag-based monitor works best across many sites, because the same tag goes on every property and reports into one inventory. Script Monitoring counts page views only, so domains, scripts and vendors are unlimited on every plan, and Pro adds multiple teams to separate brands or regions. Our client-side security tools comparison lists the alternatives.
The decisions that follow monitoring: which vendors are approved, who owns each one, what each is allowed to do, and which are blocked. Monitoring tells you what ran; management is the record of what you decided about it. See vendors and load chains.

Watch the short answers

How Do You Monitor Fourth-Party Scripts Your Vendors Load?

A third party is a vendor whose script you added; a fourth party is a script that vendor loaded. You have no contract with them and full exposure, and PCI DSS 6.4.3 applies to every script that executes on a payment page. This video shows how to see who loaded whom, why a tag manager container is judged by what it loaded rather than its name, and the four things to monitor for every script in the chain: identity and load chain, payload integrity, runtime behaviour and change over time.

Read the transcript

To monitor fourth-party scripts, watch the browser, not your vendor list. Record every script that runs in real sessions, with the script that loaded it, and get an alert when what it does changes. Here's why. You approve one vendor. It loads two more, and one of those loads another. All of them run with the same privileges as your own code. A third party is a vendor whose script you added. A fourth party is a script that vendor loaded. You have no contract with them, often no visibility, and full exposure. So approving a vendor is not approving a script. On payment pages, PCI DSS 6.4.3 applies to every script that executes, whoever added it. Tag managers are the noisiest source we see. An attacker doesn't need your container: they can inject through another one loaded as a sub-request, so the origin still reads as Google. Judge it by what it loaded, not its name. So lock the container down: MFA on every account, publish rights for a few named people, a second person to approve each publish, and limits on custom HTML tags. For every script in the chain, monitor four things: identity and load chain, payload integrity, runtime behaviour, and change over time. Most tools stop at the first. Integrity is where allowlists fail. A vendor can change what a file contains without changing its address, and an origin allowlist won't notice. Pin approval to the payload, not the URL. Behaviour is what a script does once it runs: what it touches on the page, whether it reads form fields, and where it sends data. An analytics script can read your payment form as easily as your checkout code can. The script that behaved for six months and changed last Tuesday is the interesting case. So review only what changed: new scripts, new destinations, changed code. About ten minutes a week. Script Monitoring does this from one tag, reporting every script in every session. On Pro, it also draws the full vendor load chain. Script Monitoring is free for 1,000 page views a month. Pro, with the load chain and guardrails, starts at $99 a month. Start for free at scriptmonitoring.com.

Video page with transcriptWatch on YouTube

What Are the Risks of Third-Party Scripts on Your Website?

Every third-party script on your website runs with the same access as your own code: it can read the page, read what visitors type and send data anywhere. This video covers why the set of scripts on a page is a tree rather than a list (vendors load vendors), where shadow code comes from, the six kinds of client-side attack (card skimming, credential harvesting, data leakage, malicious redirects, cryptojacking, clickjacking and overlays), why a WAF, SIEM and EDR don't see any of it, and the four things to monitor for every script: identity, integrity, behaviour and change over time. On payment pages, PCI DSS 6.4.3 & 11.6.1 have made this mandatory since 2025.

Read the transcript

The main risk of third-party scripts is that every one of them runs with the same access as your own code. It can read the page, read what visitors type, and send data anywhere, and the browser can't tell it apart from your checkout. We make Script Monitoring. It records every script that runs on your pages, in every real session, from one tag. There's no privilege boundary on a page. Your checkout code can read the card field. So can the analytics tag. So can the script that analytics tag loaded. And the scripts on your page are a tree, not a list. You approve a vendor, and the vendor loads two more. The last script in the chain is often a company you've never heard of. Approving a vendor isn't approving a script. Then there's shadow code: scripts nobody on the current team approved. A campaign tag nobody removed. A tag added by someone who has left. A plugin that ships its own scripts. So what can go wrong? Card skimming. Credential harvesting on a login form. Data leaking to third parties, usually a misconfiguration. Malicious redirects for a slice of traffic. Cryptojacking. And overlays drawn over the real interface. Your existing tools don't see it. A WAF, a SIEM and EDR all watch infrastructure you own. A skimmer posts the card from the browser straight to the attacker, so none of that traffic reaches you. And it's a moving target. The same URL can serve different code by browser, device or location. So monitor four things for every script. Where it loaded from and what loaded it. Whether its contents match what you approved. What it does, like reading form fields or sending data. And when any of that changed. Build the inventory from real sessions, not your tag manager. Delete what nobody can justify. Then review what changed, each week. On payment pages, PCI DSS 6.4.3 & 11.6.1 require this since 2025. Script Monitoring is free for 1,000 page views a month, with unlimited scripts and vendors. Pro starts at $99 a month, with a 14-day trial. Start for free at scriptmonitoring.com.

Video page with transcriptWatch on YouTube

Start with the scripts already on your checkout.

Install the tag, mark your payment pages, and see the inventory fill in. Free forever on 1,000 page views a month, no credit card.

Free forever plan. No credit card.