Who Controls the Third-Party Code on Your Website?
How a third-party script inventory, CSP, and Subresource Integrity expose security, privacy, and performance risks.
A chat widget, analytics tool, consent manager, A/B test, and embedded calendar can leave a website running more third-party code than its own team consciously understands.
The problem rarely starts with an obviously untrustworthy vendor. It starts with a script added “temporarily” that is still running on every page months later, transferring data, consuming performance, or failing without anyone knowing who owns it.
Third-party JavaScript is not neutral decoration
An externally loaded script executes in the context of your website. Depending on the integration, it may read or change content, observe forms, trigger additional requests, and load more resources. If the vendor is compromised or changes the script unexpectedly, your visitors share the risk.
Subresource Integrity, or SRI, lets browsers verify externally loaded scripts and stylesheets against an expected cryptographic hash. When the content no longer matches, the browser blocks it. This is useful for static files that can be pinned deliberately to a known version.
A Content Security Policy adds another control. The script-src directive defines which sources may provide JavaScript. CSP is not a magic switch, though. A permissive allowlist containing dozens of domains may describe the problem more than it solves it.
The deeper weakness is missing ownership
Website audits repeatedly uncover the same patterns:
- The tag manager contains old tags that nobody wants to remove.
- Marketing, an agency, and development can each add new scripts.
- A script was removed from source code but is still injected by the consent manager.
- Staging and production load different vendors.
- The privacy notice names services that no longer exist technically, or misses services that do.
- A blocked third-party script breaks navigation, checkout, or forms.
- Nobody can explain the business decision behind an external domain.
That is simultaneously a security, privacy, performance, and operational problem.
A practical third-party inventory
Document at least the following for every external resource:
- Vendor and domain: Who actually serves the code?
- Purpose: Which specific function justifies the integration?
- Owner: Who decides about changes and removal?
- Loading condition: Immediately, after consent, or only after user interaction?
- Data flow: Which requests, identifiers, or form data may be transmitted?
- Failure behavior: Does the website still work when the vendor is unavailable?
- Technical control: Self-hosted, pinned version, SRI, CSP, sandbox, or unrestricted?
- Review date: When was the need last confirmed?
This does not need to begin with an expensive governance platform. A versioned table in the repository is better than knowledge stored only in people’s heads or old tickets.
A quick browser check
Open the browser developer tools and reload a representative page. Filter the Network panel for JS, then record every domain that does not belong to your website.
Check:
- Is every domain present in the inventory?
- Is it clear what loads it?
- Is it requested before required consent?
- Does it load additional unknown domains?
- What happens when you block the domain locally?
- Are analytics or marketing tags duplicated?
- Does your CSP contain only sources that are genuinely required?
- Can static CDN resources use SRI or be self-hosted?
Repeat the test for the homepage, contact form, checkout, embedded media, and authenticated areas. Third-party code often differs between page types.
Performance belongs in the calculation
Every additional script competes for network capacity, CPU time, and the main thread. Even a small tag may load more libraries, fonts, pixels, or configuration files. The useful question is not only “How large is this file?” but “What chain does it start afterwards?”
Scripts are especially costly when they load synchronously, block rendering, create long tasks, or wait for slow vendor endpoints. A provider may optimize its own infrastructure and still damage your conversion rate.
What Website-Pflichtencheck would review
A third-party audit compares the code actually delivered with consent configuration, privacy documentation, and technical ownership. We review external domains, loading conditions, tag-manager rules, duplicate integrations, failure behavior, CSP, opportunities for SRI, performance cost, and whether critical journeys remain usable during a vendor outage.
The goal is not to ban every external tool. It is to turn accidentally accumulated foreign code into a deliberately controlled dependency.
Can you name the purpose, owner, and failure behavior of every external domain on your website today? If not, an inventory is the right first step before the next forgotten marketing tag becomes a security or revenue problem.