high Headers

Third-Party Script Risk

Every third-party script you load on your website — analytics, chat widgets, advertising, A/B testing tools — runs with full access to your page. If any of these providers are compromised, attackers can steal everything your users type, including passwords and credit card numbers.

What SecurityStatus Checks

Number and diversity of third-party script domains being loaded
Whether a Content Security Policy restricts script sources
Whether scripts are loaded with Subresource Integrity (SRI) hashes
Whether any known risky or advertising-heavy script providers are detected

Why This Matters

The Magecart attacks that stole credit card data from British Airways, Ticketmaster, and hundreds of other sites all worked by compromising third-party JavaScript. A single compromised analytics provider can turn into a skimmer on every site that uses it. This is a supply chain risk.

How to Fix It

1

Audit your third-party scripts

Open your browser DevTools Network tab and filter by Script type. List every external domain. Ask whether each one is necessary. Remove scripts from providers you do not actively use.
2

Implement Subresource Integrity (SRI)

For scripts loaded from CDNs with fixed versions, add integrity and crossorigin attributes: `<script src='https://cdn.example.com/lib.js' integrity='sha384-...' crossorigin='anonymous'>`. If the file changes, the browser blocks it.
3

Deploy a strict Content Security Policy

Use CSP to whitelist exactly which domains can serve scripts: `Content-Security-Policy: script-src 'self' https://www.googletagmanager.com https://cdn.segment.com`. Block all unlisted sources.
4

Use a tag manager carefully

Google Tag Manager and similar tools let marketers add arbitrary scripts without engineer review. Establish a process requiring security review before any new tag is added. A compromised GTM account compromises your entire site.

Frequently Asked Questions

What is a supply chain attack?

A supply chain attack targets a provider you depend on rather than attacking you directly. Compromising a single JavaScript library or analytics provider lets attackers reach thousands of websites at once.

Can I use SRI with CDN-hosted scripts?

Yes, if the file is versioned and pinned (e.g., jquery-3.7.1.min.js). For scripts that update automatically (like Google Analytics), SRI is not practical because the hash would constantly change. Use CSP to limit what those scripts can do.

Is Google Analytics a risk?

Google Analytics itself is maintained by Google and is low risk. The risk is the access it has — it can read your entire page. Using a self-hosted analytics alternative eliminates the third-party execution risk entirely.

Related Guides

Check Your Domain Now

Run all 38 security checks including Third-Party Script Risk and get your domain's security grade in under 2 minutes.

Scan Your Domain Free