How to Evaluate Third-Party JavaScript Safely

To evaluate third-party JavaScript safely, check who the vendor is, what the script loads, what data it can reach, how you can restrict it and how you remove it. Run the script on a test copy of your store first, then watch its network calls before it goes live.

This guide is for store owners and developers adding vendor widgets to a site. It applies to any widget, including the ones in virtual try-on for WooCommerce.

Why is third-party JavaScript a risk?

A script you add to your page runs with the same access as your own code. It can read what is on the page and send requests to other servers.

If the vendor is compromised, or the script changes, your shoppers are affected. That is why a quick review matters before you paste anything into a template.

What should you check about the vendor?

Start with the company, not the code.

• Who runs it, and can you find a real address and contact?
• Is there public documentation that explains what the script does?
• Does the vendor explain what data it collects and why?
• Is there a clear way to get support?

If you can't find answers, treat that as a warning.

What should you check in the script itself?

Open your browser's developer tools on a test page and look at the Network tab. Load the page with and without the script.

1. List every request the script makes and which domains it contacts.
2. Look for extra scripts it pulls in, since each is another party.
3. Check cookies and storage it sets.
4. Read what it sends. Look for data it shouldn't need.

A good vendor can explain each request.

How can you limit what a script does?

Use the controls your platform gives you.

• Content Security Policy (CSP). A CSP tells the browser which domains may load scripts and send data. See Content Security Policy and third-party widgets.
• Subresource Integrity (SRI). SRI lets the browser check that a file matches a known hash before it runs. The MDN guide to Subresource Integrity explains it. It works best for files that never change, so it fits poorly with a script the vendor updates.
• Loading on selected pages. Add the script only where it is needed, such as product pages.
• Domain-locked keys. Some vendors tie their key to your domain, so a copied key doesn't work elsewhere.

What does a safe setup look like in practice?

ZeDaq.ai's widget is one example of a script-tag install. You paste <script src="https://www.zedaq.ai/widget/zedaq.js" data-key="…" defer> into the product template. The key must be locked to your store's domain in Dashboard → API keys. The setup details are at the widget docs.

Whatever vendor you use, apply the same checks. For BigCommerce, see adding third-party widgets through Script Manager.

How do you test before going live?

Use a staging store or an unpublished theme.

1. Add the script to the test theme only.
2. Browse the pages where it runs and watch for errors in the console.
3. Test on a slow connection and on mobile.
4. Check page speed before and after.
5. Remove the script and confirm the page returns to normal.

If removing it leaves traces, such as leftover code or stored data, ask the vendor how to clean up.

What is a quick vendor review checklist?

Print this and tick it off for each new script.

• I know who the vendor is and how to reach them.
• The documentation says what the script does and what data it uses.
• I tested it on a staging copy, not the live store.
• I reviewed its network requests and cookies.
• A CSP or domain-locked key limits where it can run or be used.
• I know exactly how to remove it, and I tested removal.
• Someone on my team owns it and will review it again.

If you can't tick every box, decide whether the risk is acceptable for that page. A script on a product page carries less risk than one on checkout, where payment details are entered. Avoid adding vendor scripts to checkout unless you must.

When should you review scripts again?

Review them on a schedule, such as every quarter, and whenever a vendor announces a major change. Keep a list of every script, who owns it and why it is there.

Remove any script nobody can justify. Fewer scripts means a smaller attack surface and faster pages.

If you are building your own integration instead of using a widget, the REST API route avoids loading vendor code in the browser. See the try-on API for ecommerce developers.

FAQs

Is every third-party script unsafe?

No. Many are fine, and most stores use several. The point is to review them and limit what they can do.

Does Subresource Integrity work for every script?

It only works when the file stays the same. If the vendor updates the file at the same address, the hash will no longer match and the browser will block it.

How do I find out what a script sends?

Use the browser developer tools Network tab. Look at each request and its payload.

What should I do if a vendor is compromised?

Remove the script right away, rotate any keys and check your logs. Then ask the vendor for details before you restore it.