Content Security Policy and Third-Party Widgets

A Content Security Policy (CSP) blocks any script it doesn't list, so to run a third-party widget you add the widget's script source to your script-src directive, test in report-only mode, and then enforce the policy. Check the browser console for anything still blocked.

This matters when you add a widget such as the virtual try-on widget for WooCommerce to a store that already sends a CSP. This guide explains the idea in plain terms. For the full reference, see MDN's page on Content Security Policy.

What is a Content Security Policy?

A CSP is a rule your site sends to browsers. It lists which sources the browser may load scripts, images and other resources from. Anything outside the list is blocked.

Its main job is to limit damage if someone injects a malicious script into your page. A script that isn't allowed doesn't run.

You usually set it as an HTTP header called Content-Security-Policy. MDN notes it can also be set with a <meta> element, though that method supports fewer features.

Which directives matter for a widget?

A widget can touch several directives. These are the common ones:

Directive	What it controls	Why a widget may need it
script-src	Where scripts load from	The widget's script file
connect-src	Where the page can send requests	The widget calling its service
img-src	Where images load from	Product or result images
frame-src	What can load inside frames	A widget that opens a frame

The exact list depends on the widget. Don't guess which ones you need. Find out from the vendor's documentation and from the browser console.

How do you allow a widget step by step?

1. Read the vendor's documentation. Look for a CSP note or a list of domains.
2. Add the script source. For the ZeDaq.ai widget, the script loads from https://www.zedaq.ai/widget/zedaq.js, so your script-src needs to allow that source.
3. Run in report-only mode first. Send the new policy as Content-Security-Policy-Report-Only. Violations are reported, but nothing is blocked.
4. Load a product page and watch the console. Blocked requests show which directives need a change.
5. Add only what you need. Add each missing source to the matching directive.
6. Enforce. Once the console is clean, switch to Content-Security-Policy.
7. Test on a phone and a clean browser profile. Extensions can hide problems.

Here is a simple example, not a complete policy:

Content-Security-Policy-Report-Only: script-src 'self' https://www.zedaq.ai

The ZeDaq.ai docs describe the widget tag in the widget section. They don't publish a full CSP list, so use the console to see what your own page needs.

What about inline scripts and nonces?

If your policy blocks inline scripts, a script tag pasted into a template may be blocked too. A nonce solves this. It is a random value the server creates for each response, placed in both the policy and the script tag's nonce attribute. The browser runs only scripts whose nonce matches.

A nonce must change on every response, so it works on server-rendered pages but not on fully static HTML.

For a script loaded by a src URL, allowing the host in script-src is the simpler route.

How should you choose which third-party scripts to allow?

Each domain you add widens what the browser will trust. Keep the list short.

Ask these questions about every widget:

• Do we need it on every page, or only on product pages?
• Is the vendor clear about what it loads and what data it sends?
• Can we lock it to our domain? ZeDaq.ai requires the widget key to be locked to your domain.
• Does the vendor publish a documented list of required sources?

Our guide to evaluating third-party JavaScript safely goes deeper on vetting scripts, and the walkthrough for BigCommerce Script Manager shows how one platform handles widget installs.

What common mistakes break widgets?

• Enforcing a new policy without testing in report-only mode first.
• Allowing a whole domain family when one host is enough.
• Forgetting connect-src or img-src, so the widget loads but fails to work.
• Testing only logged in as an admin, where plugins add exceptions.
• Setting a CSP in a <meta> tag and expecting report-only behavior, which <meta> can't deliver.

What if you build your own integration?

If your developers prefer to call the API directly instead of loading a widget, a script from a third party is not needed on the page. The API is called from your server with an x-api-key header, so your CSP may not need a new script source. See the try-on API for ecommerce developers.

FAQs

Will a strict CSP block the ZeDaq.ai widget?

If your script-src doesn't allow https://www.zedaq.ai, the browser will block the script. Add the source and test.

Is report-only mode safe on a live store?

Yes. It reports violations without blocking anything, so it is the usual way to test a new policy.

Do I need a nonce for the widget?

Not if your policy allows the script's host. You need a nonce if your policy blocks inline scripts and you paste the tag inline.

Where do I find which sources a widget needs?

Check the vendor's documentation first, then load the page with the console open and read the blocked-request messages.