Third-party scripts and privacy

What it is

A third-party script is any <script src="…"> whose source is not your own origin. Once it loads, it runs with full access to the page: the DOM, cookies that are not HttpOnly, localStorage, the URL, the referrer, form inputs as the user types, and any data your own JavaScript exposes.

The browser also tells the third party about the visit at the network layer: IP address, user-agent, Accept-Language, the page that loaded the script (Referer), and any cookies that domain has set.

Why it matters

Third-party scripts are the largest source of unintended data leaks on the modern web. A single tag for a chat widget, A/B tester, fonts service, or "session replay" tool can ship every URL a logged-in user visits to a third party. Some of those tools record keystrokes by default.

From a legal standpoint, the EDPB has confirmed that the ePrivacy Directive applies to any technology that reads or writes to the user's device, not just cookies — so a tracking pixel without a cookie is still in scope. From a security standpoint, a compromised third-party script becomes a compromise of your site. Magecart-style supply-chain attacks have hit British Airways, Ticketmaster, and many smaller sites by injecting code into a single trusted vendor.

How to implement

Treat every third party as a liability you are choosing to take on.

• Audit what you have. Use the network panel, or a tool like Request Map, to list every domain your pages contact. Most sites are surprised.
• Justify each one. What does it do, who owns it, what data does it receive, and what is the business case for keeping it? Anything that fails this should be removed.
• Self-host where you can. Fonts, JavaScript libraries, and icon sets rarely need to come from a CDN. Self-hosting eliminates a third-party contact entirely and is often faster.
• Defer or gate the rest. Anything that is not essential to first render should load after user interaction, or only after consent for non-essential storage.
• Use a Content Security Policy. A script-src allowlist prevents a compromised page from loading scripts you did not approve. See security/content-security-policy.
• Use Subresource Integrity for any script you must load from a third party where the URL is stable. An SRI hash ensures the file has not changed since you audited it. See security/subresource-integrity.
• Set a Referrer-Policy of strict-origin-when-cross-origin or stricter so third parties do not see full URLs.

Common mistakes

• Loading dozens of marketing tags through a tag manager and treating the tag manager as the audit.
• Hot-linking fonts or libraries from a public CDN to "save bandwidth" while leaking visitor IPs to that CDN.
• Adding session-replay tools without checking what they record. Many capture passwords and credit cards by default.
• Setting a permissive CSP (script-src *) that defeats the protection.
• Auditing once at launch and never again.