1 Introduction
Open your homepage and the browser does not load one file, it loads dozens: your own HTML and images, but also an analytics tag, a chat widget, fonts from a font service, a JavaScript library from a public CDN, a cookie banner, an advertising pixel. Each of those comes from someone else's server, and each script among them runs inside your page with the same power as your own code.
That makes every external script a supplier with the keys to your website. If one of those servers is hacked, sold or simply expires, the code your visitors receive changes, without anything changing on your side. The "Network requests" block of a domain scan shows you who those suppliers are.
June 2024
The polyfill.io CDN, bought by a new owner, starts serving malicious code to the sites that load it
100,000+
Websites reported to be embedding polyfill.io at the time
1
HTML attribute, integrity=, makes the browser refuse a file that was changed
2 How It Works
A line like <script src="https://cdn.vendor.com/widget.js"> tells every visitor's browser to fetch that file and run it, every time, as it is now. You checked the file once when you added it; the browser never checks it again.
You include
Your page references a script hosted by a third party: a CDN, an analytics service, a widget vendor.
They change it
The vendor updates the file, gets breached, sells the domain, or lets it expire and someone else registers it.
Visitors run it
The new code runs in your visitors' browsers, on your domain, with access to everything on the page.
What a script on your page can do
Read every form field as it is typed (passwords, card numbers, addresses), read cookies that are not marked HttpOnly, change the page content, swap the bank details on an invoice page, redirect visitors to a phishing site, or send all of it to any server. The browser treats it as your code. Images, fonts and stylesheets are less dangerous (they cannot run code) but still tell the third party who visits you and when.
3 Detailed Analysis
Reading the "Network requests" block
The capture is run on demand: you press "Load network requests", and a headless browser opens your homepage (or any URL you type) and records every request the page makes. It counts as one domain scan against your quota. Each row shows the method, HTTP status, resource type (script, stylesheet, font, image, xhr, fetch...), the full URL, the MIME type, size, duration and remote IP.
Sort by host, then by type
Group the URLs by domain. Requests to your own domain are yours. Everything else is a third party: write each one down with what it is for. Pay most attention to the script rows: those run code.
Failed requests are not just noise
A script that fails because its domain no longer exists is a dormant risk: if anyone re-registers that domain, your page will run their code. Remove the reference rather than waiting.
Hosts you do not recognise
Scripts often load other scripts. A tag manager can pull in a dozen hosts you never added yourself. Each one is still running on your page: trace it back to the tag or plugin that loads it.
What the block does not check
It lists requests, it does not judge them, and it sees only the page it loaded. It does not tell you whether a script uses SRI or is allowed by your CSP: you check that in your page source and headers, as described below.
Browser-side supply chain attacks
polyfill.io (2024)
A popular free service that served compatibility code for old browsers. Its domain changed hands in early 2024, and in June researchers found it injecting malicious redirects into the pages of sites that loaded it. Those sites had changed nothing. If polyfill.io appears in your requests, remove it today: modern browsers rarely need it.
Magecart and web skimming
"Magecart" is the name given to groups that inject card-stealing code into checkout pages, often by compromising a third-party script rather than the shop itself. The British Airways breach of 2018, where payment data was skimmed from its website, is the best known case.
The lesson
Fewer third-party scripts means fewer suppliers who can hurt you. On sensitive pages (login, checkout, account) load as little external code as possible.
Subresource Integrity (SRI)
SRI pins a file to its exact content. You add the file's hash to the tag; if the server ever sends something different, the browser refuses to run it:
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/library.min.js"
integrity="sha384-BASE64_HASH_OF_THE_FILE"
crossorigin="anonymous"></script>Compute the hash yourself from the file you reviewed:
curl -s https://cdn.jsdelivr.net/npm/[email protected]/dist/library.min.js \
| openssl dgst -sha384 -binary | openssl base64 -APin a version, never "latest"
SRI only works on a file that never changes, so the URL must contain an exact version. A URL that always serves the newest release will break the hash at the next update.
crossorigin="anonymous" is required
For a file on another domain, the browser can only check the hash if the request is made with CORS. Without the attribute the check cannot run and the file is blocked.
Where SRI does not fit
Analytics tags, payment SDKs and chat widgets change their file on purpose, often daily, so a hash would break them. For those, rely on the vendor's trust, limit them with CSP, and keep them off pages where they are not needed.
Self-hosting and Content-Security-Policy
Self-host what you can
A library or a font copied to your own server cannot be changed by anyone else, does not leak your visitors to a third party, and removes one supplier. You then own its updates: track them with your other dependencies.
Limit the origins with CSP
A Content-Security-Policy header lists the hosts allowed to serve scripts. Anything else is blocked, including a script injected later. Start with Content-Security-Policy-Report-Only to see what would break, then enforce.
Content-Security-Policy: script-src 'self' https://cdn.jsdelivr.net https://www.googletagmanager.com; object-src 'none'; base-uri 'self'The privacy angle: trackers and GDPR
Every third-party request sends the visitor's IP address and the page they are on to that third party. For trackers and advertising pixels this is the whole point, and under the GDPR it usually requires consent before the request is made.
Check what loads before consent
The capture loads the page without clicking the cookie banner. Any tracker in the list therefore fires before consent. That is a compliance problem as much as a security one.
Even fonts count
In January 2022 a Munich court ruled that loading Google Fonts from Google's servers without consent breached the GDPR, because it sent the visitor's IP to Google. Self-hosting fonts avoids the question.
List your page's third parties on mlab.sh
A domain scan can load your homepage in a headless browser and list every request it makes, so you see each external host your visitors' browsers talk to.
Scan your domain on mlab.sh4 Red Flags
A script from polyfill.io or another known-compromised host
Remove the tag today. If it was there in mid-2024, assume your visitors may have received malicious code and review what the page handles.
A script whose domain no longer exists
Anyone who registers that domain gets to run code on your site. Remove the reference now, it costs nothing.
Third-party scripts on login or checkout pages
These pages handle passwords and card numbers, exactly what skimmers want. Keep only what the page cannot work without.
CDN libraries without integrity=
A versioned file on a public CDN is the easiest case for SRI. Add the hash, or self-host the file.
Trackers firing before the cookie banner is answered
A GDPR issue on top of a security one. Configure your consent tool to block them until the visitor agrees.
Related Modules
HTTP security headers explained
HSTS, CSP, X-Frame-Options, cookie flags: what each header blocks, what a missing one means in a scan, and a safe configuration to start from.
Known vulnerabilities on your website
How a scan matches software versions to CVEs, what CVSS, EPSS and CISA KEV mean, and how to prioritise patching.
Third-party services in your DNS
Verification tokens in TXT records reveal your SaaS suppliers to attackers. What they expose and how to clean them up.
Source: mlab Academy — Cybersecurity Awareness Platform
URL: https://academy.mlab.sh//page/third-party-scripts
Module: Third-party scripts and browser supply chain — Secure your domain
Disclaimer: This content is for awareness purposes only.