If you asked most website operators how many third-party scripts their site loads, they would guess five or six. The real number is usually 15 to 40. Every one of those scripts runs with the same privileges as your own code — it can read form inputs, redirect users, set cookies, and exfiltrate data to any server it wants. A single compromised script is all it takes to steal credentials, inject ads, or skim payment details. The good news is that auditing your third-party scripts is not difficult. It just requires a methodical approach and a couple of hours. Here is how to find every external script on your site and decide which ones to keep.

Step 1: Open DevTools and list every external domain

Open your site in Chrome. Open DevTools with F12 or Cmd+Option+I on Mac. Go to the Network tab. Reload the page. In the filter bar, click "JS" (or type script into the filter). Now look at the Domain column. Every domain that is not yours is a third-party script.

Common ones you will see: googletagmanager.com, cdnjs.cloudflare.com, js.stripe.com, connect.facebook.net, cdn.jsdelivr.net, and www.google-analytics.com. Right-click the table header and make sure the Domain column is visible if it is not already showing.

Export the list by right-clicking in the Network panel and selecting "Save all as HAR with content." This gives you a JSON file you can parse later. Or simply screenshot the list and drop it into a spreadsheet. Either way, this is your starting inventory.

Step 2: Check for dynamically loaded scripts

The Network tab only shows what has loaded so far. Some scripts load other scripts after the page renders. Google Tag Manager is the classic example — it appears as one <script> tag in your HTML, but at runtime it can inject dozens of additional scripts depending on your GTM configuration. Analytics platforms, consent managers, and A/B testing tools do the same thing.

To catch these late-loading scripts, wait at least 10 seconds after the page finishes loading before you export your list. Better yet, interact with the page — click buttons, open modals, scroll to the bottom — because some scripts are lazy-loaded on user interaction. Then switch to the Sources panel in DevTools. The left sidebar shows a tree of every domain that has served a script to the page, including ones that loaded after the initial page render. This gives you the complete picture that the Network tab alone might miss.

If you use Google Tag Manager, also log into your GTM account and review the container. List every tag that loads an external script. GTM containers have a tendency to accumulate tags over time as different team members add tracking, and nobody removes the old ones.

Step 3: Check SRI (Subresource Integrity) status

For each external script in your inventory, check whether its <script> tag includes an integrity attribute. You can do this by viewing your page source (Ctrl+U in Chrome) and searching for each external domain.

Subresource Integrity hashes ensure the browser only executes the script if its content matches a known cryptographic hash. If the CDN is compromised and serves different code, the browser blocks execution entirely. A script tag with SRI looks like this:

Most third-party scripts will not have SRI, and there is a reason. Vendors like Google, Facebook, and HubSpot update their scripts frequently without changing the URL. The file at https://connect.facebook.net/en_US/fbevents.js today is not the same file it was last week. SRI would break every time they push an update. That is a deliberate design choice by the vendor — and a risk you should document. For each script in your inventory, note whether SRI is present, feasible, or impossible due to vendor-managed auto-updates.

Step 4: Assess each vendor

Now that you have your full inventory, go through each third-party domain and answer five questions:

What does this script do? Categorize it: analytics, payment processing, chat widget, advertising, A/B testing, font loading, social media embed, or something else. If you cannot determine what a script does, that is a red flag.

Is it still needed? This is where most audits pay for themselves. In our experience, roughly 20% of third-party scripts on a typical site are from tools nobody uses anymore. The marketing team tried a heatmap tool six months ago, the trial expired, but the script tag is still in the template. The old analytics platform was replaced but never fully removed. These are dead weight with live risk.

Has the vendor been breached? Check against known supply chain incidents. The Polyfill.io takeover in 2024 affected over 100,000 websites when the domain was sold to a Chinese company that injected malicious redirects. The Codecov breach exposed secrets from thousands of CI/CD pipelines. The ua-parser-js hijack pushed cryptominers to seven million weekly npm downloads. If a vendor has been compromised before, it does not necessarily mean you should drop them — but you should verify they have improved their security practices since.

Is SRI feasible? For scripts loaded from a pinned CDN URL with a version number in the path (like cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js), yes — add SRI. For vendor-managed scripts that auto-update at a fixed URL, SRI will break when the vendor pushes a new version.

Can you self-host it? For open-source libraries like jQuery, Bootstrap, or Font Awesome, self-hosting eliminates the CDN as a risk entirely. Download the file, serve it from your own domain, and you no longer depend on a third party to deliver unmodified code. The tradeoff is that you lose automatic updates and shared CDN caching, but for security-critical applications that tradeoff is worth it.

Step 5: Remove what you do not need

The single easiest security win from a third-party audit is deleting scripts nobody uses. No configuration, no hash generation, no vendor negotiation. Just delete the script tag. Common culprits include: A/B testing scripts from experiments that concluded months ago. Analytics from a platform you switched away from. Chat widgets from a free trial that expired. Tracking pixels from ad campaigns that have been paused. Social sharing buttons that nobody clicks. Font preloaders for fonts you no longer use.

Every removed script is one fewer attack vector, one fewer external dependency, and one fewer DNS lookup slowing down your page load. It is the rare case where improving security also improves performance.

After removing unused scripts, check your site thoroughly. Some scripts have hidden dependencies — removing one might break a feature you did not realize depended on it. Test all critical flows: login, checkout, form submissions, and any interactive features.

Step 6: Document and monitor

After your audit, you have a clean, documented baseline inventory of every third-party script your site loads and why it is there. Put this in a spreadsheet or a wiki page with columns for: domain, purpose, owner (who on your team requested it), SRI status, and last review date.

The problem is that this inventory is a snapshot. It goes stale the moment someone updates a tag manager container, installs a WordPress plugin, or adds a new marketing tool. Scripts get added through multiple channels — direct HTML edits, CMS plugins, tag managers, third-party widgets that load their own dependencies — and rarely does anyone run the audit again afterward.

That is why continuous monitoring matters. You want to be alerted when a new third-party domain appears on your site that was not in your approved inventory. You want to know when an existing script's content changes unexpectedly. You want to catch it when someone adds a script tag to your GTM container without going through your review process.

Automating the audit

The manual DevTools approach described above works well for a one-time review, but doing it monthly by hand is not sustainable. For ongoing monitoring, BlackSight Scanner automates this entire process. It visits your site in a real browser, waits for dynamic scripts to load, catalogs every third-party script and the domain it originates from, checks SRI compliance on each one, flags vendors with known breach history, and alerts you when anything changes between scans.

The supply chain scan takes about 90 seconds and covers all the checks described in this article. The free tier includes one scan per month — enough to establish your baseline and run periodic manual checks. The Plus plan at $29/month gives you unlimited scans and scheduled monitoring, so you get an alert the moment a new third-party script appears on your site rather than discovering it during your next quarterly review.

Conclusion

A third-party script audit is one of the highest-impact security tasks you can do in an afternoon. The steps are straightforward: list every external script, check for dynamically loaded ones you missed, verify SRI coverage, assess each vendor, and remove what you do not need. Most teams find scripts they can delete immediately, which is a security improvement that costs nothing and speeds up their site as a side benefit.

Start with the manual DevTools approach. Get your baseline inventory. Remove the dead scripts. Add SRI where feasible. Document what remains and who is responsible for each one. Then automate the monitoring so your inventory does not go stale the moment you close the spreadsheet.

The scripts running on your site have the same access as your own code. You should know exactly what they are and why they are there.