Third-Party Scripts on Your Site: Every Tag Is a Risk

Open your website right now and count how many external services it loads. Google Analytics. Google Tag Manager. Facebook Pixel. A live chat widget. Google Fonts. jQuery from a CDN. A cookie consent banner. A YouTube embed. A Twitter feed. A customer review widget. A heatmap tool like Hotjar.

The average business website loads between 15 and 30 third-party scripts. Some ecommerce sites load 40 or more. Every single one of those scripts runs with full access to your web page. They can read form inputs. They can modify the page. They can intercept clicks. They can redirect visitors. They can steal data.

If any one of those third-party services is compromised, your visitors are affected. Not because you did anything wrong, but because you trusted someone else's code to run on your pages.

This is supply chain risk applied to the web, and it is one of the most underestimated security threats facing businesses today.

What Third-Party Scripts Can Do on Your Page

When you add a third-party script to your website (a <script> tag pointing to an external domain), that script runs with the same permissions as your own code. There is no sandbox, no restriction, no boundary. It has full access to:

• The entire DOM: It can read and modify every element on the page. It can inject new elements, hide existing ones, or change text and links.
• Form data: It can read everything a user types into forms, including passwords, credit card numbers, personal information, and login credentials.
• Cookies: It can read cookies that are not marked as HttpOnly, including session tokens and tracking data.
• Local storage and session storage: It can read and write to the browser's local storage, where applications often store tokens and user preferences.
• Network requests: It can make HTTP requests to any domain, including sending collected data to external servers.
• User interactions: It can attach event listeners to track clicks, scrolls, mouse movements, and keystrokes.

This is by design. The web platform does not provide any way to give a script partial access. It is all or nothing. When you include a third-party script, you are giving that third party the same level of access to your page as you have yourself.

The Supply Chain Problem

Supply chain attacks on websites work like this: instead of attacking your website directly, an attacker compromises one of the third-party services your website depends on. When the compromised service delivers its modified script to your visitors, the malicious code runs on your pages as though you put it there yourself.

For a deeper look at how supply chain attacks work in the context of CMS plugins, see our article on supply chain attacks through plugins.

Why Supply Chain Attacks Are Effective

• Scale: Compromising one popular third-party library or service can affect thousands or millions of websites simultaneously. An attacker who compromises a widely-used analytics script can harvest data from every site that uses it.
• Trust: Website owners trust their third-party providers. The scripts load automatically on every page view. Nobody is manually reviewing the code that loads each time.
• Stealth: The malicious modification may be subtle, perhaps adding a few lines of code that only activate on checkout pages, or only for visitors from specific regions. This makes detection difficult.
• Persistence: As long as your website loads the compromised script, the attack continues. And since scripts are loaded from the third party's server, the attacker can modify the payload at any time without touching your website.

The British Airways Case: A $230 Million Lesson

The British Airways data breach of 2018 is one of the most instructive examples of a third-party script attack. Attackers injected a malicious script (later identified as part of the Magecart group's operations) that specifically targeted the airline's payment page.

What Happened

The attackers modified a script loaded on the British Airways website. The modified script was just 22 lines of JavaScript. When customers entered their payment details on the checkout page, the script copied the credit card number, expiry date, CVV, and cardholder name, and sent this data to a server controlled by the attackers.

The attack ran for approximately 15 days before it was detected. During that period, approximately 380,000 payment card details were stolen.

The Consequences

• The UK Information Commissioner's Office (ICO) initially proposed a fine of 183 million GBP under GDPR. This was eventually reduced to 20 million GBP.
• British Airways faced a class-action lawsuit from affected customers.
• The brand suffered significant reputational damage.
• Customer trust in the airline's digital channels was severely impacted.

And the root cause was a third-party script modification. The airline's own servers were not directly breached. The attack happened in the browser, through code that ran on the customer's machine.

For more on payment page attacks, see our article on web skimming in ecommerce.

Common Third-Party Scripts on Business Websites

Let us go through the third-party scripts typically found on business websites and discuss the risk each one introduces.

Analytics and Tracking

• Google Analytics / GA4: Loaded on nearly every business website. Tracks page views, user behavior, conversions. Runs extensive JavaScript on every page. If Google's script delivery infrastructure were compromised (unlikely but not impossible), the impact would be enormous.
• Google Tag Manager: This one is particularly powerful. GTM is essentially a platform for loading and managing other scripts. Anyone with access to your GTM container can deploy arbitrary JavaScript on your website without touching your code repository. If an attacker gains access to your GTM account, they have unrestricted access to modify what runs on your pages.
• Facebook/Meta Pixel: Tracks user behavior for advertising purposes. Sends detailed interaction data to Facebook servers.
• Hotjar, Crazy Egg, FullStory: Session recording and heatmap tools. These scripts capture user interactions in detail, including where they click, how far they scroll, and sometimes what they type.

Advertising and Marketing

• Google Ads conversion tracking: JavaScript snippet that fires when a conversion occurs.
• LinkedIn Insight Tag: Tracks visitor behavior for LinkedIn advertising targeting.
• Various retargeting pixels: Criteo, AdRoll, and others. Each one is a script that tracks your visitors across the web.

Functionality

• Live chat widgets: Intercom, Drift, Zendesk Chat, Tidio. These load significant JavaScript and often include the ability to inject overlays and pop-ups on your pages.
• Customer review widgets: Trustpilot, Google Reviews, Yelp widgets. Load external content onto your page.
• Social media embeds: Twitter/X feeds, Instagram galleries, YouTube players. Each one loads scripts from the respective platform.
• Maps: Google Maps embeds load scripts from Google's servers.
• Captcha: Google reCAPTCHA loads scripts from Google that interact with your forms.

Infrastructure

• CDN-hosted libraries: jQuery, Bootstrap, or other libraries loaded from public CDNs like cdnjs, jsDelivr, or unpkg.
• Web fonts: Google Fonts, Adobe Fonts (Typekit), and others load font files and associated CSS from external servers.
• Cookie consent platforms: CookieBot, OneTrust, CookieYes. These scripts manage cookie consent and often load before everything else.

How to Audit Third-Party Scripts on Your Site

The first step toward managing this risk is understanding exactly what your website loads. Most website owners cannot produce a complete list of third-party scripts on their site. Here is how to create one.

Method 1: Browser Developer Tools

1. Open your website in Chrome or Firefox.
2. Open Developer Tools (F12).
3. Go to the Network tab.
4. Reload the page.
5. Filter by "JS" to see JavaScript files.
6. Look at the "Domain" column. Any domain that is not your own is a third-party script.
7. Repeat for key pages: homepage, contact page, product pages, checkout page.

Method 2: Online Scanners

Tools like BuiltWith, Wappalyzer, or RequestMap can scan your site and show you all external resources loaded. These give you a quick overview but may not catch scripts that only load conditionally (e.g., only on mobile, only after user interaction, or only for visitors from certain regions).

Method 3: Content Security Policy Report-Only

The most thorough approach is to deploy a Content Security Policy in report-only mode. This tells browsers to report (but not block) every resource loaded on your page that comes from a domain not in your approved list. Over a few days, this will give you a complete picture of every external resource your site loads.

What to Record

For each third-party script, document:

• The domain it loads from.
• The purpose it serves.
• Who in your organization added it and when.
• Whether it is still needed.
• Whether the provider has a security track record (have they been breached before?).
• What data it has access to on your pages.

Subresource Integrity (SRI)

Subresource Integrity is a browser security feature that allows you to verify that scripts loaded from external sources have not been tampered with. It works by including a cryptographic hash of the expected file content in the script tag.

How SRI Works

<script src="https://cdn.example.com/library.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
  crossorigin="anonymous"></script>

When the browser downloads the script, it calculates the file's hash and compares it to the hash in the integrity attribute. If they do not match (meaning the file has been modified), the browser refuses to execute the script.

Limitations of SRI

• Only works for static files. If the third-party script changes frequently (like analytics scripts that are updated regularly), the hash will not match after each update and the script will break. This makes SRI impractical for many third-party scripts.
• Does not work with dynamically generated scripts. Some third-party services generate JavaScript dynamically based on configuration, making it impossible to pre-calculate a hash.
• Requires manual updates. Every time the external script is legitimately updated, you need to update the hash on your site.

Where SRI Is Effective

SRI works well for versioned libraries loaded from CDNs. If you load jQuery 3.7.1 from a CDN, you know exactly what the file should contain, and it should never change. Adding SRI to this script tag protects against CDN compromise.

Content Security Policy (CSP)

A Content Security Policy is an HTTP header that tells the browser which sources are allowed to load resources on your page. It is the most powerful defense against third-party script attacks, but it is also one of the most complex to implement correctly.

What CSP Controls

CSP can restrict:

• script-src: Which domains can provide JavaScript.
• style-src: Which domains can provide CSS.
• img-src: Which domains can provide images.
• font-src: Which domains can provide fonts.
• connect-src: Which domains can receive AJAX/fetch requests.
• frame-src: Which domains can be embedded in iframes.
• object-src: Which domains can provide Flash/Java objects (should be set to 'none').

A Practical CSP Example

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com;
  style-src 'self' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' https://www.google-analytics.com data:;
  connect-src 'self' https://www.google-analytics.com;

This policy allows scripts only from your own domain, Google Tag Manager, and Google Analytics. Any script from a domain not in the list will be blocked by the browser. If an attacker manages to inject a script tag pointing to their server, the browser will refuse to load it.

CSP Challenges

• Inline scripts: Many third-party services require inline scripts (script tags directly in the HTML). CSP blocks these by default unless you use 'unsafe-inline' (which defeats much of the purpose) or nonce/hash-based allowlisting.
• Third-party chains: Google Tag Manager loads other scripts, which may load yet more scripts. You need to allow every domain in the chain.
• Breaking functionality: A CSP that is too restrictive will break your site. Testing in report-only mode first is essential.
• Maintenance: Every time you add a new third-party service, you need to update your CSP.

Self-Hosting Critical Resources

One of the most effective ways to reduce third-party risk is to self-host resources instead of loading them from external CDNs.

What You Can Self-Host

• Fonts: Instead of loading Google Fonts from fonts.googleapis.com, download the font files and serve them from your own domain. This eliminates a third-party dependency and also improves performance (one fewer DNS lookup and connection).
• JavaScript libraries: Instead of loading jQuery, Bootstrap, or other libraries from public CDNs, include them in your build process and serve them from your own domain.
• CSS frameworks: Same as JavaScript libraries. Self-host them.
• Icons and images: Font Awesome, icon libraries, and stock images loaded from external CDNs can be self-hosted.

What You Cannot Easily Self-Host

• Analytics scripts: Google Analytics needs to communicate with Google's servers. Self-hosting the script file does not help because the script still needs to send data externally.
• Live chat widgets: These require a persistent connection to the chat service's servers.
• Embedded content: YouTube videos, social media feeds, and maps need to load from their respective platforms.

Performance Impact of Third-Party Scripts

Security is not the only reason to be concerned about third-party scripts. They have a significant impact on page performance.

How Third-Party Scripts Slow Down Your Site

• DNS lookups: Each external domain requires a separate DNS lookup. 10 third-party scripts from 10 different domains means 10 additional DNS lookups.
• Connection overhead: Each external domain requires a separate TLS handshake and HTTP connection. This adds latency.
• Render blocking: Scripts in the <head> block page rendering until they are downloaded and parsed. A slow third-party server can make your entire page load slowly.
• Main thread blocking: JavaScript execution happens on the browser's main thread. Heavy third-party scripts block all other processing, causing jank and unresponsiveness.
• Layout shifts: Third-party content (ads, widgets, embeds) that loads after the initial page render can cause layout shifts, a negative user experience and a factor in Google's Core Web Vitals.

Measuring the Impact

Google Chrome's Lighthouse audit includes a "Reduce the impact of third-party code" recommendation that specifically identifies third-party scripts that block the main thread. Run a Lighthouse audit on your site and check this section. The results are often eye-opening.

As a rough benchmark: every third-party script adds somewhere between 50ms and 500ms to your page load time, depending on the script size, the server response time, and how much work the script does on execution. With 20 third-party scripts, you can easily add 2-5 seconds to your page load time.

Privacy Implications Under GDPR

Third-party scripts are not just a security and performance issue. They are a privacy and compliance issue, particularly under GDPR and the Swiss nLPD.

What Third-Party Scripts Do with Data

Many third-party scripts collect and transmit user data to external servers. Google Analytics collects behavioral data. Facebook Pixel tracks user activity for advertising. Hotjar records user sessions. Each of these constitutes processing of personal data under GDPR.

Compliance Requirements

• Consent: Under GDPR, you need informed consent before loading tracking scripts. This means your cookie consent banner must actually block these scripts until the user consents, not just inform them. Many implementations fail here: they show a banner but load the scripts regardless.
• Data processing agreements: You need a data processing agreement (DPA) with every third-party whose script processes personal data on your behalf.
• Privacy policy disclosure: Your privacy policy must list every third-party service that collects data through your website, what data they collect, and why.
• Cross-border transfers: If a third-party script sends data to servers outside the EU/EEA (which Google Analytics, Facebook Pixel, and most US-based services do), you need appropriate safeguards for cross-border data transfers.

A Practical Action Plan

Reducing third-party script risk does not mean removing everything. It means being intentional about what you include and implementing appropriate safeguards.

Step 1: Audit and Inventory

Create a complete list of every third-party script on your website. For each one, document its purpose, who added it, and whether it is still needed. This alone often reveals scripts that were added years ago for a campaign that ended long ago.

Step 2: Remove What You Do Not Need

Be honest about what is actually providing value. Do you look at your Hotjar recordings? Do you use the data from the LinkedIn Insight Tag? Is that Twitter feed widget on the homepage adding anything? If a script does not provide clear business value, remove it. Fewer scripts means fewer risks, better performance, and simpler compliance.

Step 3: Self-Host Where Possible

Move fonts, JavaScript libraries, CSS frameworks, and icon fonts to your own hosting. This reduces the number of external dependencies without losing any functionality.

Step 4: Implement SRI for Static Resources

For any external resources that you cannot self-host but that have stable file contents (versioned libraries), add SRI hashes to the script and link tags.

Step 5: Deploy a Content Security Policy

Start with a report-only CSP to understand what your site loads. Then gradually tighten the policy, adding specific domain allowlists and removing unsafe directives. This is the most effective long-term protection against script injection.

Step 6: Use Tag Manager Carefully

If you use Google Tag Manager, restrict access to the GTM container. Enable two-factor authentication for all GTM users. Review what is deployed in GTM regularly. Consider whether each tag is still needed and whether it was added by someone who is still with the organization.

Step 7: Monitor

Set up monitoring to detect changes in the third-party scripts loaded on your site. Tools like Report URI (for CSP violation reports) or dedicated script monitoring services can alert you when a new external resource appears on your pages.

The Modern Alternative: Fewer Scripts, Better Architecture

Modern web architecture, as we discuss in other articles on this blog, favors fewer dependencies and simpler technology stacks. A statically generated site deployed to a CDN does not need most of the third-party scripts that a traditional dynamic site relies on.

Server-side analytics (like Plausible or Umami) can replace Google Analytics without loading any client-side script. A simple contact form can be handled by a serverless function instead of a third-party form service. Fonts can be self-hosted. Libraries can be bundled into your build.

The result is a faster, more secure, more private website that is also easier to maintain and simpler to keep compliant with data protection regulations.

Next Steps

If you are concerned about the third-party scripts on your website (and after reading this article, you should be), we can help. At Envestis, we perform website security assessments that include a thorough audit of third-party scripts, their security implications, their performance impact, and their compliance status.

Contact us for an assessment. We will give you a clear picture of your third-party exposure and a practical plan to reduce it.