What Content Security Policy (CSP) do I need for Channels?
PreviousWhat Channels Clusters Exist?NextWhat happens if a user is on a poor connection that occasionally drops? Will they miss messages?
Last updated
Last updated
Whitelisting `*.pusher.com` and `*. 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.
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 .
We utilize 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 .