A New Third-Party Script Appeared: How to Review It

A website change report flags a script domain you do not recognize. It could belong to a newly approved chat widget, an agency's tag-manager change, or a component that no longer belongs on the site. The domain alone does not answer that question.

Start by preserving the script URL, affected page, and observation time. Do not approve it merely because the name resembles a familiar vendor, and do not remove it from production before checking whether it supports an important visitor action.

Trace how the script arrived

Inspect the original HTML and the browser's Network panel. A script can be included directly in a template or loaded by another script after the page starts running. The request initiator can help connect a downstream request to the component that loaded it.

Write the loading path in plain language: “The site layout loads our tag manager, and the published container version loads the chat vendor.” This is more useful than a flat list of hostnames because it tells the team where a change would need to be made.

Repeat the check under the consent states relevant to the site. A script that appears only after an optional choice may have a different intended role from a script that loads on the first page request. Inspect actual behavior rather than inferring it from a banner label.

Ask for ownership evidence

Give the responsible team a small set of questions:

• What feature needs this script, and who owns that feature?
• Which approved change introduced it?
• Where is it configured: template, plugin, tag manager, or another loader?
• On which pages and visitor states should it run?
• How can it be disabled and tested if a problem appears?

Confirm the domain against the vendor's own documentation or configuration, not just a search result for its name. Ask whether the resource changed host during a vendor migration. A legitimate change still needs a clear owner and a testable reason to remain.

Review behavior as well as identity

An expected vendor does not make every integration correct. Check whether the script appears on pages where it is unnecessary, loads more than once, blocks a key action, or produces new console errors. Have the appropriate owner review data handling separately if the integration changes what is collected or transmitted.

For a concrete example, suppose a chat widget is intended only for the public support page but a shared template loads it on account settings too. The useful fix may be scoping the integration, not changing the vendor or treating the domain as inherently suspicious.

Choose a bounded decision

An approval record should identify the purpose, owner, expected pages, source configuration, and date. If the change is unexplained, escalate it to the person who can inspect the application and deployment history. If containment is needed, preserve the evidence and test the effect of disabling the responsible integration.

For fixed external assets, Subresource Integrity can help browsers verify that the fetched bytes match an expected hash. It needs suitable integration, and cross-origin resources require the relevant CORS support; it is not a universal drop-in solution for frequently changing vendor scripts. MDN documents the mechanism and its constraints.

Verify after the decision

After removal or reconfiguration, repeat the same public requests and consent states. Test the feature that previously depended on the script. A missing network request is useful evidence, but a broken support form is not an acceptable side effect to overlook.

Keep an inventory that is short enough to maintain. A hostname, purpose, loader, owner, and last review date are enough to begin. Review changed entries during releases instead of repeatedly approving the entire list.

The existing security headers guide explains the surrounding browser controls. Script review adds the operational question those headers cannot answer: who intended this code to run here, and why?