Allowing the widget through your Content Security Policy

If your site sends a Content Security Policy (and it should), the widget needs three origins allowed. Miss one and it fails silently: the snippet is on the page, nothing appears, and the only sign is a line in the browser console.

Content-Security-Policy:
    script-src  'self' https://widget.talkfront.app;
    frame-src   https://widget.talkfront.app;
    connect-src 'self' https://widget.talkfront.app;

What each one is for

script-src loads loader.js, the small script that draws the chat button.

frame-src is the chat window itself, which runs in an iframe on our origin. That is also why your page’s CSS and JavaScript cannot reach into it, or it into yours.

connect-src is the one people miss. Before it draws anything, loader.js asks us for your widget’s settings: its title, colour and position. Blocked, there is no chat button at all, which looks like the snippet never arrived.

The console is explicit when this happens:

Refused to connect to 'https://widget.talkfront.app/v1/sites/…/config'
because it violates the document's Content Security Policy.

What you do not need

You do not need to allow our WebSocket host. The live connection is opened by the chat window, inside the iframe, which is a different origin with its own policy. Adding wss://ws.talkfront.app to your own connect-src does no harm and no good.

Testing it

Load a page with the policy on and open the browser console. A blocked script, frame or connection says so by name, so you are never guessing which directive is short.

If the policy is set by a proxy or a platform rather than your own code, check there too. A header added in front of your application will not be in your repository.

Still stuck? The widget isn’t appearing on my site works down the other causes, and a CSP is only one of them.

Last updated 22 September 2026.