Home / Knowledge hub / Third-party script risk
Knowledge hub
Third-party script risk
Code from outside vendors running on your pages with the same powers as yours.
What it means
Third-party script risk comes from loading JavaScript written and hosted by someone else: analytics, chat widgets, tag managers, payment forms, ad code. Once it runs on your page, the browser treats it as your own code, with no separate walls between them.
That means it can read what the visitor types, see page content, set cookies and call other servers. The vendor's security becomes part of yours, whether or not you ever chose that. A weakness at the vendor, or a change in who owns the script's domain, reaches your customers without any change on your side.
Why it matters
A script that can read the page can read a card number or a password as it is typed. Payment skimming through a compromised script is a well-known pattern, and your customers will blame the shop, not the vendor. The browser sees no difference between your code and theirs.
There is also a plain business cost. Standards such as PCI DSS expect you to know which scripts run on payment pages and why. Without an inventory, you cannot answer that question for an assessor, or for yourself after an incident, and nobody can say who approved a given script.
How it shows up
You meet it as a tag manager that marketing can edit without review, a widget added years ago for a campaign that ended, or a script loaded from a domain that has since changed hands. Each one runs on every page that includes it.
Start with a list of what loads and who approved it. Remove what nobody uses. Where the vendor allows it, pin a file with subresource integrity and limit sources with a content security policy. Keep sensitive pages, such as login and checkout, as bare as possible.
Questions people ask
Third-party script risk, answered
Is a third-party script the same as a dependency in our code?
They are alike but not the same. A dependency is bundled into your build, where you can review and pin it. A third-party script is usually fetched live from the vendor each time a page loads, so the code can change without you doing anything.
Does a content security policy solve it?
It helps a lot, but it does not solve it alone. A policy can limit which domains scripts load from. It cannot judge what an allowed script then does, so an approved vendor that is compromised still runs with full page access.
Can subresource integrity protect every script?
No. It works for files that never change, because the browser compares a hash to the file. Many vendor scripts update constantly or load further code themselves, so a fixed hash would break them or miss what they pull in.
Why are payment pages a special concern?
They handle card data and credentials, so a single malicious script there can steal valuable information quickly. This is why payment standards ask you to inventory and justify scripts on those pages.
How often should we review the scripts we load?
Review on every addition, and on a regular schedule, such as quarterly. Also check after a vendor changes ownership or reports a security incident. An old script nobody owns is the usual weak spot.
Sources
Where this comes from
Related
Terms that sit next to this one
Subresource integrity
A hash check that stops a tampered third-party script or stylesheet from loading.
Content Security Policy
A header telling the browser which scripts a page may load.
Vendor risk management
Judging and monitoring the security of the suppliers your business relies on.
DOM-based XSS
Script injection that happens in the browser's own code, not in the server's response.
Mixed content
An HTTPS page loading some resources over plain HTTP, which can be tampered with.
What else runs on your pages?
Pages that pull in outside scripts, and the policies meant to contain them, are part of what we test in the running app. Findings come with the request and response that prove them. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.