Treat a script as code inside the visitor’s session
A small analytics or chat tag can look like a harmless line in a website template. Once loaded, however, JavaScript runs in the visitor’s browser as part of the page. OWASP’s third-party JavaScript guidance identifies loss of control over changes, execution of arbitrary code and disclosure of sensitive information as central risks. A vendor may update a hosted script without the site owner deploying anything. The effect depends on what page and data the script can reach. A tag on a public news page has a different exposure from the same tag beside a customer address form or checkout. The decision should therefore name the page, purpose and access, not just the vendor brand.
Start with an inventory of scripts actually delivered to a browser. Check the website template, tag manager, embedded widgets and partner code, then inspect network requests on representative pages. Record who requested each tag, the business purpose, pages where it loads, host, data sent, and how it can be disabled. A tag manager is a deployment route, not proof that every tag inside it is approved. Include scripts added by plugins and payment or scheduling tools. The list should reflect observed browser behaviour as well as configuration, because an old snippet can remain active after a campaign owner leaves.
Ask whether the page needs the tool
For every tag, ask what customer or staff decision it improves and whether the same purpose can be met with less browser access. A live chat widget may be useful on a service enquiry page but unnecessary on a payment confirmation containing order details. A conversion tag may need an event that an order completed, not the full address or free-text form fields. Separate essential customer functions from measurement and promotion so that a business owner can decide whether the benefit warrants the access. OWASP notes that analytics tags can read page context and send information to the vendor; review the actual fields and URLs rather than assuming a generic description of the tool limits what it sees.
A workable decision record has four outcomes: keep on specific pages, restrict to a narrower set of pages, replace with a less intrusive method, or remove. The decision also names the person authorised to change it and the condition for reconsideration, such as a new checkout design or a vendor script URL change. Avoid a blanket rule that all external scripts are forbidden if a customer function truly needs one; instead document why it is needed and where it is allowed. Likewise, do not keep a tag merely because no one remembers why it was installed.
Understand what integrity checks can and cannot do
Subresource Integrity, or SRI, lets a browser compare a fetched script or stylesheet with a declared cryptographic hash. MDN explains that a mismatch prevents the resource from loading. For a versioned static library from a CDN, this can protect against an unexpected change to those exact bytes. Cross-origin SRI also requires the remote server to permit CORS and the page to request the resource appropriately. Test that combination in the real browser before rollout. A hash copied from an untrusted source or generated for the wrong release proves little, and an intended vendor update will fail until the expected hash is deliberately changed.
SRI is not a universal switch for dynamic vendor tags. A tag designed to change at the same URL may break under a fixed hash, while a script deliberately approved at a given version can still behave in ways the business does not want. Review the tool’s data flows and customer-page scope separately. OWASP lists SRI and local mirroring among possible defences against uncontrolled code changes, but each has operating costs: someone must manage versions, test updates and respond when the script fails. If a script cannot be pinned, make the exception explicit, narrow the pages where it runs and keep a working disable route.
Use browser policy as a tested boundary
A Content Security Policy can limit which script sources a page may load. OWASP describes CSP as a browser-enforced defence in depth measure, including restrictions on remote and inline scripts. For a small website, the practical starting point is to list the origins the page actually requires, then test a proposed policy against its critical journeys. A broad allowlist covering many vendor domains can undermine the intended boundary; a policy copied from another site can break checkout or leave unnecessary permissions. Ask the implementer to explain each exception in ordinary language and test it on the pages where customers enter or review information.
CSP and SRI answer different questions. CSP governs where and how page resources may load; SRI checks whether specified fetched bytes match an expected hash. Neither checks that a vendor’s commercial terms, privacy handling or user interface are acceptable. A script can pass a hash check and still collect more information than the team intended. A policy can allow a trusted host but cannot make every future script from that host useful. Treat the technical controls as layers supporting a documented decision, and arrange for someone to review violation reports or failures instead of setting a header once and forgetting it.
Walk a tag through an actual customer journey
Imagine a retailer wants to add a new analytics tag to learn whether a delivery-information page helps shoppers. The manager first states the exact event needed: a visit to that public guidance page and perhaps a click to view delivery options. The team checks whether the tag also loads on address entry and order confirmation through a shared template. It inspects the outgoing requests with a test account containing synthetic details, checks URLs and request fields, and records the result. If the tag fires across checkout by default, the team changes its scope before launch. No real customer details are needed for this rehearsal.
Then test the page with the tag blocked or its vendor unavailable. Can shoppers still read delivery information, choose an option and place an order? A non-essential measurement tool should not quietly become a single point of failure for the customer journey. Ask the owner to show how the tag is disabled in an incident, who receives a broken-page report, and how the business will tell a script failure from a failed payment. These are operational acceptance checks, not claims that a particular vendor is unsafe. Repeat them when the script, site template or data fields materially change.
Review what a vendor change actually alters
An approved tag is not approved forever in every form. When a vendor changes its script URL, adds a new endpoint or alters the information sent, the owner should compare the live behaviour with the recorded purpose. Rehearse a normal update in a test environment: confirm that the right pages still load the tag, inspect requests with synthetic data, verify core customer actions, and update any pinned SRI hash only after the new bytes are reviewed and expected. If a dynamic tag cannot be pinned, the review of endpoints and scope becomes more important. A release note from the vendor is useful context but does not replace observation of the site’s own page.
Also document a stop condition. For example, if a tag begins reading a customer form field outside the approved event, causes the order button to fail, or points to an unexplained new host, the person on duty should know how to disable it and who decides whether to restore it. Capture the page, time, script identity and observed request without copying real customer content into a ticket. Once the issue is understood, test the essential customer path with the tool off, then make a fresh keep, restrict or remove decision. This gives the team a specific response to drift rather than relying on a vague promise to monitor vendors.
Make changes reviewable after launch
Give each script a named owner and a small change record: purpose, approved pages, vendor endpoint, expected data, control used, last test and disable route. Before a campaign team adds a new tag through a manager, it should present the same information. A quarterly review may be a reasonable internal rhythm for one small site, but the proper frequency depends on how often its pages and vendors change; no source here sets a universal interval. The valuable point is that someone compares the live page with the approved inventory, since configuration and actual browser behaviour can drift apart.
The immediate next action is to open one public page, one customer-data form and one order result page in a test browser, and list the external scripts each loads. Mark any script whose owner or purpose is unknown. Ask the business owner to decide the page-level purpose before a developer implements a control. This creates a bounded task that a small team can finish and verify. It also makes the commercial trade-off visible: a tool may provide useful service or measurement, but its benefit should be named alongside the data it can see and the support burden it creates.
Before you proceed
- Each live tag has an owner, purpose and approved page scope.
- Test requests show what data leaves representative pages.
- Critical customer flows work when a non-essential vendor is unavailable.
