Audit the Third-Party Code Your Interface Loads

Security & Access · security, design systems, performance

Updated 2026-08-04

Know every script your pages load and why. Analytics, chat widgets, session recorders, ad tags, and font services all execute with the same privileges as your own code.
Understand the exposure. A supply chain attack does not need to breach your servers, because the compromised dependency is already running inside your users' sessions on your domain.
Keep a list with an owner for each entry. Third-party scripts accumulate through campaigns and experiments, and the ones nobody owns are the ones nobody removes.
Ask what each one can see. A session recorder on a checkout page is watching card fields, and a chat widget on an account page is inside an authenticated session.
Pin versions rather than loading whatever is current. A tag that always fetches the latest build hands a stranger the ability to change your product without a deploy.
Restrict what the page is allowed to load. A policy that names the permitted sources turns an injected script into a blocked request rather than a running one.
Measure the cost as well as the risk. Third-party code is frequently the largest single contributor to how slow a page feels and the hardest to attribute.
Remove on a schedule. Every tag should have a review date, because the experiment ended two years ago and the script is still loading.

Every script you include is a decision to trust someone else with your users' sessions, and that decision deserves the same review as a dependency in your own codebase.