Content Security Policy

Answered

29 Comments

  • Ramin Shokrizadeh
    Comment actions Permalink

    Hi Tore,

    Weird that the post disappeared, not aware that any of us took it down for a particular reason.

    The good news is we released a change in the last week to better support CSP. 

    Now, if you use CSP on your site or specify unsafe-eval or unsafe-inline the widget will work now but with one caveat. The widget will only work in English. 

    The change breaks how the widget handles translations and it is a bigger project to change this piece of the code. 

    So if you just need the widget to be in English, the change we released this week should resolve your problem with CSP support. 

    Thanks,

    Ramin

    0
  • Tore Amundsen
    Comment actions Permalink

    Hi Ramin,

     

    I have tried the English version to see if that solved all the CSP violation errors without success.

    We wan't to gain as much protection as possible from CSP. Our configuration is fine grained. We enable full protection by default. And do modifications on a detailed level (directive, protocol, host, port etc) when needed. Unsafe-inline and Unsafe-eval is not permitted as this basically disabling most of the security that CSP offers.

    Can you please specify exactly what policies (directives, hosts, protocols, ports etc.) we need to apply to make the widget work without CSP violations.

    Thanks,

    Tore

    0
  • Ramin Shokrizadeh
    Comment actions Permalink

    Hey Tore,

    The widget should work in English with the strictest CSP options. Can you send me a link to your website so the team can look and see why it isn't working for you?

    Thanks,

    Ramin

     

    0
  • Tore Amundsen
    Comment actions Permalink

    I'm sorry, but the current policy is in a closed development environmet and can't be access outside our local network.

    With a strict policy without anything configured for Zopin, I get this violation in Chrome:

    Refused to load the script 'https://v2.zopim.com/?3RTWi9A994wKeF9Ax64lzOKXe44FWhlq' because it violates the following Content Security Policy directive: "script-src 'self'

    If I then enable v2.zopin.com by adding to the srcript-src diretive, I get other errors:

    • Refused to connect to 'wss://de12.zopim.com/s/W/ws/pO2-the9-9In7S7S/c/1450181863773' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.
    • Uncaught SecurityError: Failed to construct 'WebSocket': Refused to connect to 'wss://de12.zopim.com/s/W/ws/pO2-the9-9In7S7S/c/1450181863773' because it violates the document's Content Security Policy.

    If I then enable web socket for de12.zopim.com (wss://de.zopim.com) for the connect-src directive, I get  a bunch of other violations. Some of them:

    • Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'. Either the 'unsafe-inline' keyword, a hash ('sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='), or a nonce ('nonce-...') is required to enable inline execution.
    • Refused to load the image 'https://v2assets.zopim.io/3RTWi9A994wKeF9Ax64lzOKXe44FWhlq-concierge?1447749609826' because it violates the following Content Security Policy directive: "img-src 'self'

    And It goes on...

    Please use Chrome and start our with a simple default CSP of "content-security-policy: default-src 'self'", and I think you will be able to reproduce what I'm experiencing.

    Thanks,

    Tore

     

     

    0
  • John Nguyen
    Comment actions Permalink

    Hi Tore,

     

    My apologies for the confusion about the level of CSP support that our widget provides.

     

    To sum up, at the current stage, this is a sample CSP header that works with Zopim chat widget (assuming your site are full https)

    add_header Content-Security-Policy "default-src 'self' https://*.zopim.com wss://*.zopim.com https://*.zopim.io; style-src 'unsafe-inline'";

     

    To reduce the widget's load time, we deployed multiple servers around the globe e.g. us01.zopim.com, de01.zopim.com, jp01.zopim.com ...

    This helps our widget's users leverage the better network connections between our data centers instead of going through the normal busy routes. It also helps our regional data caching as well.

    This explains the wildcard used on our domains above.

    - we use *.zopim.com for our shared assets and realtime connection endpoints

    - we use secure websocket wss as our realtime transport of choice

    - we use *.zopim.io for user-created content like avatar, file uploads. A separate domain helps the security of our assets on zopim.com as well.

    - we dynamically create inline <style/> tags and font files from our one javascript bundle. It helps the bundling and save us from new http requests overhead. So, in the mean time, we need the "style-src 'unsafe-inline'" rule :(

     

    Hope this clear things out and provides more info about some decisions that we made :)

    And thank  you for your detailed post above. It shows us that we need to up the level of CSP support we provide.

     

    Cheers,

    John

     

     

    0
  • Tim Hodson
    Comment actions Permalink

    Hi John,

    This is really useful information and would be great to see an article on this somewhere.

    We're currently using CSP on our own web applications in report mode but want to switch to 'real' mode as soon as possible, however the Zopim widget poses a challenge as the use of unsafe-inline is a no-no.

    While we don't use zopim, one of our customers does (loaded into our site) and we're currently in a position that if we enable our CSP rules, we will break functionality that is important to one of our customers.  

    It would be great to know what the roadmap is for addressing this issue?

    0
  • Ramin Shokrizadeh
    Comment actions Permalink

    Hi Tim,

    Thanks for the feedback around making this a help center doc somewhere, will see what we can do to make it happen.

    In terms of the roadmap to further improve our CSP support, it will require some fairly big changes to the widget and we are not in a position to do those changes right now. We are monitoring the requests for this to aid in shaping the roadmap going forward but nothing is planned for the next two quarters that would address this.

    If/when the team begins to work on it, we will update the thread to let everybody know. 

    Thanks,

    Ramin

    0
  • Tore Amundsen
    Comment actions Permalink

    Hi Ramin,

    It is about a year since I first asked aboat the CSP support and found out that important parts was missing. Has this security important issue made its way to your roadmap now?

    Thanks,

    Tore

    0
  • Ramin Shokrizadeh
    Comment actions Permalink

    Hi Tore,

    Thanks again for reaching out. We are exploring what options we have without breaking other components of the widget but are not committing to anything in the next 6 months.

    We understand the value of expanding the CSP support but the team are focused on delivering other features at the moment.

    -Ramin

    0
  • Tore Amundsen
    Comment actions Permalink

    Hi Ramin,

    Any updates on this issue?

    Tore

    0
  • Ramin Shokrizadeh
    Comment actions Permalink

    Hi Tore,

    It isn't on the 2017 roadmap at the moment. If that changes, I will let you know here.

    -Ramin

    0
  • Alin
    Comment actions Permalink

    Hello,

    Does anyone knows how this CSP tags should be updated to work with connect-src wss://*.zopim.com     ?

    Apparently adding that (prepended by ;  before the end of the ") it doesnt solve the problem. All resources are working fine, is just this kind of error left:

    Refused to connect to 'wss://de20.zopim.com/s/W/ws/tRRnRbxAwhjfuHQm/c/1488545722309' because it violates the following Content Security Policy directive: "default-src https: data: 'unsafe-inline' 'unsafe-eval'". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.

     

     

    Header unset Content-Security-Policy
    Header add Content-Security-Policy "default-src * 'self' data: 'unsafe-inline' 'unsafe-eval' https: wss:"
    Header unset X-Content-Security-Policy
    Header add X-Content-Security-Policy "default-src * 'self' data: 'unsafe-inline' 'unsafe-eval' https: wss:"
    Header unset X-WebKit-CSP
    Header add X-WebKit-CSP "default-src * 'self' data: 'unsafe-inline' 'unsafe-eval' https: wss:"
    0
  • eyal
    Comment actions Permalink

    Any updates on this subject? This is the only source blocking me from implementing a tight CSP... This issue has been here since 2015, I hope there has been any progress ?

    0
  • Jakob Waller
    Comment actions Permalink

    Hi, I'd also like to know if there are any updates on this? The widget is of great value to us and our users but we also need to have a good CSP without e.g. unsafe-inline.

    0
  • Ramin Shokrizadeh
    Comment actions Permalink

    Hi Jakob,

    Currently, there is no immediate plans to change the CSP support of the standalone Chat widget. There might be some small improvements for the Chat experience in the Web Widget in the coming months, but not at the level that people are requesting for at the moment. Will share more regarding the Web Widget changes when the timing is right, is ready to be used.

    Thanks,
    Ramin

    -1
  • Tim Guo
    Comment actions Permalink

    Hi, we're adopting our web app to the Chinese language, and when we switch our app language to Chinese, we get this violation in Chrome:


    'Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'sha256-xNWy6QHCwZRdRIztPmws2tVXB'

    After debugging, we realized it caused by the zopim widget which injects the line script in Chinese mode. Is there any way to remove the inline script from the DOM in non-English mode? BTW, due to our security policy, we are unable to add 'unsafe-inline' to the CSP. 

    0
  • Joe
    Comment actions Permalink

    Hi, I'm also having trouble with this. I'm getting

    `Refused to execute inline script because it violates the following Content Security Policy directive: "script-src *". Either the 'unsafe-inline' keyword [...]`

    when trying to load the chat. An earlier reply suggests unsafe inline is only necessary for styles, but it seems like it's necessary for scripts too from this error and this article https://developer.zendesk.com/embeddables/docs/widget/csp

    1
  • Timothy Sotack
    Comment actions Permalink

    Hi,

    I was quite disappointed to learn that 'unsafe-inline' is required for use of the Web Widget. This effectively means I have to use 'unsafe-inline' on most pages when using the standard integration with the Web Widget.  I would like to request  trying to make it work without this requirement as it significantly impairs the usefulness of CSP. Is there another chat  integration that you can recommend that does not require putting the widget on every page?

    Tim S

    1
  • Mickaël Fourgeaud
    Comment actions Permalink

    Still no news? 

    0
  • Jimmy McDermott
    Comment actions Permalink

    This is pretty upsetting to see. We can't adopt the Chat widget until it doesn't require `unsafe-inline` because we're not going to sacrifice the security of the site for one feature that, admittedly, would be very helpful. I'm disappointed in the lack of response for this and will be keeping this in mind when we discuss which vendors to renew in the upcoming fiscal year. 

    0
  • Ramin Shokrizadeh
    Comment actions Permalink

    Hi Jimmy,

    If you are using the Zendesk Web Widget, we are working on improving the CSP support overall and part of it is visible in the integrated chat experience EAP. Although it doesn't support the strictest mode, the Web Widget team are working to eventually get there. 

    You can learn more about the EAP here: https://support.zendesk.com/hc/en-us/community/posts/360000879927-Start-Here-Web-Widget-Integrated-Chat-Experience-Early-Access-Program-EAP-

    For customers using the Chat standalone widget, we do not have plans in 2018 to change the CSP support.

    -Ramin

     

     

    0
  • Jimmy McDermott
    Comment actions Permalink

    Hi Ramin,

    This is certainly a nice improvement to the situation. I will check it out now. Thanks! 

    0
  • Joe
    Comment actions Permalink

    Hi Ramin,

     

    Delighted to hear that the CSP issues are being addressed.  Are you able to share a roadmap for the new chat app?  

    Joe


    0
  • Ramin Shokrizadeh
    Comment actions Permalink

    Hi Joe,

    We do not publicly disclose our roadmap, but we did just announce the Limited Availability of the new widget experience today. You can learn more about it here: https://support.zendesk.com/hc/en-us/articles/360002088268

    -Ramin

     

    0
  • Prudhvi Reddy Avula
    Comment actions Permalink

    Hi Ramin,

    Is there an update on this issue? It looks like this has been an issue from the last 4 years. We can't use "style-src 'unsafe-inline'" as per our security policy. Is there a workaround for this other than loosening our CSP?

     

    - Prudhvi

    0
  • Ramin Shokrizadeh
    Comment actions Permalink

    Hi Prudhvi,

    There are no changes for the Chat standalone widget. CSP for the Web Widget has improved overall and is documented here: https://developer.zendesk.com/embeddables/docs/widget/csp

    -Ramin

     

    0
  • Prudhvi Reddy Avula
    Comment actions Permalink

    Hi Ramin,

    We are using web widget by following the recommended approach using nonce, listed here - https://developer.zendesk.com/embeddables/docs/widget/csp. Is still doesn't work. It works only when unsafe-inline is added for style-src.

     

    - Prudhvi 

    0
  • Ramin Shokrizadeh
    Comment actions Permalink

    Prudhvi Reddy Avula please create a ticket by emailing support@zendesk.com and the Web Widget team can investigate further or update the docs if required. Thanks. 

    0
  • Prudhvi Reddy Avula
    Comment actions Permalink

    Thanks Ramin. I just emailed support@zendesk.com. Hoping that this issue can be resolved without adding unsafe-inline in our style-src header.

     

    -Prudhvi

    0

Please sign in to leave a comment.

Powered by Zendesk