Every external script on your website is a potential attack vector. The 2024 Polyfill.io incident compromised over 100,000 websites when the domain was acquired by a malicious actor who injected malware into a widely-used JavaScript library. Supply chain attacks are the fastest-growing threat to web security.
What Is a Supply Chain Attack?
A supply chain attack targets the third-party code your website depends on, rather than your website directly. When an attacker compromises a library, CDN, or service that your site uses, every website loading that resource becomes a victim.
Notable Supply Chain Attacks
| Incident | Year | Impact |
|---|---|---|
| Polyfill.io | 2024 | 100,000+ websites served malicious redirects |
| UA-Parser-JS | 2021 | NPM package hijacked to install crypto miners |
| Codecov | 2021 | CI/CD tool backdoored to steal credentials |
| Magecart | 2018-now | Payment card skimmers injected via third-party scripts on e-commerce sites |
| Event-Stream | 2018 | NPM package compromised to steal bitcoin wallets |
Common Third-Party Risks on Websites
- Analytics scripts (Google Analytics, Hotjar, Mixpanel) — transmit user behavior data
- Advertising pixels (Facebook, Google Ads, LinkedIn) — track users across sites
- Chat widgets (Intercom, Crisp, Tawk.to) — have full page access
- Payment processors (Stripe, PayPal embeds) — handle sensitive financial data
- CDN-hosted libraries (jQuery, Bootstrap, Font Awesome) — could be compromised at the CDN
- Social embeds (YouTube, Twitter, Instagram) — set cookies and track users
How to Protect Your Website
1. Audit Your Dependencies
First, know what's on your site. Run a PrivacyChecker scan to identify all external scripts, their origins, and what data they access. Many website owners are surprised by the number of third-party scripts they didn't knowingly add — often injected by CMS plugins, themes, or tag managers.
2. Implement Subresource Integrity (SRI)
SRI ensures that external scripts haven't been tampered with by verifying a cryptographic hash:
<script src="https://cdn.example.com/lib.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
crossorigin="anonymous"></script>If the file changes (even one character), the browser blocks it. Generate SRI hashes at srihash.org.
3. Use Content Security Policy
CSP limits which domains can serve scripts to your page. See our security headers guide for implementation details.
4. Self-Host Critical Libraries
Instead of loading jQuery or other libraries from public CDNs, download and host them on your own server. This eliminates the risk of CDN compromise and improves loading performance.
5. Monitor for Changes
Set up continuous monitoring to detect when third-party scripts change. PrivacyChecker's drift detection alerts you when external scripts are modified, added, or removed — so you can verify the changes before they affect your visitors.
GDPR Implications
Under GDPR, you are responsible for the data processing done by your third-party scripts, even if you didn't write them. If a compromised script steals visitor data from your site, you are liable. This makes vendor risk assessment a compliance requirement, not just a security best practice.
Action Checklist
| Action | Difficulty | Impact |
|---|---|---|
| Audit all third-party scripts | Easy | High — know your attack surface |
| Add SRI to external scripts | Easy | High — prevents tampered code |
| Implement CSP | Medium | High — blocks unauthorized scripts |
| Self-host critical libraries | Easy | Medium — eliminates CDN risk |
| Remove unused scripts | Easy | High — reduces attack surface and improves performance |
| Set up continuous monitoring | Easy | High — catches changes before they cause damage |
Start with a free PrivacyChecker scan to see every third-party script on your website, categorized by type and risk level. Pro+ includes supply chain security monitoring with alerts.