The chat widget and Content-Security-Policy: what to allow

If your site uses a CSP, the chat may silently fail to load. Here are the directives the widget needs — and why it no longer needs unsafe-inline.

Content-Security-Policy is a header a site uses to tell the browser where scripts, styles and data may be loaded from. It is useful protection, but strict: anything not explicitly allowed gets blocked, and without any visible error on the page. That is why the most common complaint from sites with a CSP sounds like this: “we added the code, but there is no chat button”.

Three directives for the widget

The widget loads a script, pulls in its own styling and exchanges messages with the server. So the Webchatix domain needs to be in three directives:

• script-src — so the script itself can load;
• style-src — for the chat’s stylesheet;
• connect-src — for sending and receiving messages.

If images are shared in the chat, add the same domain to img-src as well: image previews are loaded from our server. The exact snippet and the list of directives are in the “Website widget” section of the documentation.

Why unsafe-inline is not needed

The widget used to inject its styles straight into the page with a <style> tag, so sites with a strict policy had to keep 'unsafe-inline' in style-src. A hash or nonce did not help: the widget updates itself, so the hash would change with every release. Now the styling lives in a separate file on our domain — allow the domain and you need no inline exceptions at all.

If your policy is older

Sometimes the domain is already listed in script-src and connect-src but missing from style-src. For those sites the widget has a fallback: if inline styles are allowed on the page, it fetches the same stylesheet and injects it itself. The chat looks exactly the same, but the proper fix is still to add the domain to style-src.

The other side: allowed origins

CSP protects your site, while the Allowed origins (CORS) field in the site settings protects your chat: it decides which addresses the widget will accept connections from at all. An asterisk * is convenient while testing, but on a live site it is better to list your own domains, separated by commas. More on this and other measures in the “Security and GDPR” section.

A one-minute check

Open a page with the widget, then the developer console (F12). If the CSP blocked something, you will see a message naming the directive — that is the one to extend. No button and a clean console? Check that the site key in the snippet matches the key in the dashboard and that your domain is on the allowed list; both points are also in the FAQ. Still stuck? Get in touch and include your site’s CSP header.