Build a Third-Party Script Inventory You Can Review and Act On

A useful third-party script inventory explains why each script is present, who owns the decision, where it runs, and what happens if it changes or disappears. A list of vendor names is a start, but it cannot support a security, privacy, or performance decision without those details.

Begin with the scripts that actually load in the browser, then trace each back to its source in the site: template, plugin, tag manager, embedded widget, or another script. The observed page and the configuration should agree.

Define what belongs in the inventory

Include externally hosted scripts and locally hosted code supplied by an outside vendor when it performs an external service function. Also record scripts introduced through tag managers or embedded tools, since they may not appear in the main application repository.

A script can load additional scripts. Treat that chain as part of the review rather than assuming the first visible vendor is the whole dependency.

OWASP's third-party JavaScript guidance describes the risks associated with code executing in a page's context. The inventory should therefore focus on actual execution and access, not only contractual vendor relationships.

Keep ordinary images, fonts, and other external resources in related records if useful, but distinguish them from executable scripts so the review does not lose its purpose.

Capture the actual loading path

Use browser developer tools and the site's configuration to identify the script URL, initiating resource, page or route, and conditions under which it appears. Test relevant states such as signed out, signed in, consent choices, and checkout.

Record the full dependency path. A marketing tag manager may load a vendor script that then loads another service. Knowing only the final domain makes it harder to find the control that can remove it.

Do not assume that removing a script tag from one template removes the service everywhere. A plugin, theme setting, or embedded form may add it through another route.

Use a representative page set rather than only the homepage. Account pages, forms, checkout, and campaign landing pages often have different script behavior.

Repeat the observation in a clean browser profile and in a normal returning-visitor state. Stored consent choices, experiments, and cached configuration can change what loads. Record the state with the evidence so an absent request is not mistaken for proof that the integration has been removed for every visitor.

Give each script an accountable purpose

Write the business function in one sentence: collects a specified analytics event, provides a chat interface, renders a payment field, or supports a map. Avoid labels such as miscellaneous or required without an explanation.

Assign an owner who can decide whether the function is still needed. The person who installed a script may no longer be responsible for the service it supports.

Record the user-visible consequence of removal. If no one can identify a consequence or current purpose, investigate whether the script is obsolete. Do not remove it from production solely because the name is unfamiliar; first test the dependency.

The vendor-assessment guide can help connect the technical record with the supplier relationship and support route.

Describe page access and data flow

A script running on a page may be able to interact with page content and events depending on how it is integrated. Identify which pages expose sensitive information and whether the script needs to run there.

Record the categories of information sent to external endpoints. Use observed requests and vendor documentation rather than assuming that a product's analytics label limits what it receives.

The FTC's explanation of online data collection provides context for why collection and sharing need to be understood. Your site's actual behavior should inform its notices and choices.

Do not include secrets or personal payloads in a widely shared inventory. Record field categories and safe examples, keeping any detailed evidence in an appropriately controlled location.

Review how code changes reach the site

Some integrations reference a fixed version; others load whatever the vendor currently serves. Determine which model applies and who can change it.

A tag manager can make changes without an application deployment. That may be operationally useful, but its publishing permissions and review process become part of the control system.

Ask whether the vendor announces changes and whether you can test them before they affect critical pages. A service that changes remotely can break a flow even when your own repository has not changed.

Record the last observed version or content identifier where meaningful. Do not imply that a timestamp alone proves the code has been reviewed.

Use controls according to what they actually do

W3C Subresource Integrity describes checking a fetched resource against expected integrity metadata. This can help detect unexpected content changes for suitable resources, but it does not establish that the approved script's behavior is safe.

A frequently changing vendor script may not fit a simple fixed-integrity setup without a planned update process. Understand the integration before adding a control that could silently block a critical function.

The security-headers guide explains related browser controls. A content-security policy can restrict sources and behavior, but a broad allowlist should not be mistaken for a review of everything those sources can execute.

Test controls in a representative environment and inspect violations. A configuration that looks strict while allowing the actual unwanted path has not achieved the intended result.

Include performance and failure behavior

Measure when the script loads and whether it blocks rendering, delays interaction, or creates repeated network work. The website-speed guide helps connect those observations to user experience.

Also test what happens when the vendor is slow or unavailable. A chat widget should not prevent the main form from working unless that dependency is an intentional requirement.

For critical integrations, define a fallback or a clear error. A blank payment area is different from an optional map failing to load. The inventory should reflect that difference in priority.

Avoid treating every script with a large file size as equally harmful. Loading timing, caching, execution cost, and the page's purpose all affect the result.

Turn the inventory into decisions

Use a compact record with the script, loading path, purpose, owner, page scope, data categories, change model, controls, and proposed action. Actions might include retain, restrict to fewer pages, replace, update, or remove after testing.

Assign a review date based on the script's role and change pattern. A critical remotely changing integration deserves different attention from a stable optional resource.

Connect privacy changes to the website privacy-policy review. Updating text without checking the actual data flow, or changing the data flow without reviewing the text, leaves the two out of alignment.

Keep unresolved questions visible. An unknown recipient of data is a review item, not a blank cell that becomes tacit approval.

Verify removal and keep a baseline

When a script is approved for removal, test the relevant workflows and confirm that its requests no longer appear in the states where it previously loaded. Check for a second installation through a plugin or tag manager.

Save a small baseline of expected external script domains and owners. Compare future observations with that baseline during relevant releases or audits.

The inventory succeeds when a new or changed script leads to an understandable decision. It should let the team explain why executable third-party code is present, what it can affect, and how to change the integration without guessing.