What Content Security Policy (CSP) do I need for Channels?

Simple CSP

Whitelisting `*.pusher.com` and `*.pusherapp.com` will allow all connections to our Channels service. This is slightly less restrictive than the below policy but is the quickest to implement, and will also ensure any future subdomains and linked functionality we introduce is not blocked.

Advanced CSP

This list allows for a more fine-grained approach to defining your CSP.

If making use of the CDN (http:// or https://) script-src: js.pusher.com If on mt1 (main) cluster (ws:// or wss://) connect-src: ws.pusherapp.com If on any other cluster (ws:// or wss://) connect-src: ws-[your-cluster].pusher.com

You would need to add ws/wss and http/https depending on whether you are encrypting your Channels connection. If you are using a cluster other than mt1 (main cluster) then you need to add the ID of that cluster where it says [your-cluster]. E.g. for cluster 'eu', you would need to add ws://ws-eu.pusher.com. You can find out the cluster of your app on the dashboard.

SockJS fallback

We utilize SockJS as a fallback should a websocket connection fail. To maintain a successful SockJS connection with clients we are required to expose individual endpoints for each SockJS host. This means it is not possible to provide strict CSP rules for SockJS connections and so wildcards are required, as per the Simple CSP implementation described above.

If wildcard rules are not appropriate for your implementation then you can disable the SockJS transport using the disableTransports connection option.

Still have questions? Please reach out to our Support team by visiting this page.