Allow for specifying a CSP nonce when initialising a Widget

Community Discussion Feature Requests
1

Our site uses a Content Security Policy (CSP) that disallows unsafe-inline styles and scripts, and instead requires either a nonce generated per request to be attached to scripts, or the hashes for styles / scripts to be specified in the CSP.

The tawk.to widget has a lot of these inline scripts and styles, and it has no way to specify a nonce to be attached to these. Instead, we have to use the hashes of most of the styles, as well as the unsafe-hashes to account for the large amount of inline styling used in the widget.

Additionally, the styles for the widget animations (most namely the minimise and maximise animations) use randomly generated classes & IDs, causing their hash to change and making it impossible to properly allow these through our CSP.

The request I’d like to make is the following:

  • Allow for specifying a nonce on widget initialisation (as an optional variable) that can then get attached to all scripts and styles as the widget loads.
  • Move any current inline styles (such as style="width: 100%; height: 100%;" into style tags with a class, so that we don’t need to specify unsafe-hashes in the CSP.
  • Use non-statically generated IDs (or a class) for the widget animation styles attached to the iframes, so that these can be properly hashed.
  • After customising a widget, it would be helpful to be provided the script / style hashes within the tawk.to interface so that they don’t need to be rooted out within the devtools console. I understand if this one is harder to implement, as I imagine the styles are likely generated at widget runtime.
2

Hi RobLyons,
Thank you for your detailed feature request and providing us with such thorough context on your specific needs. We understand the necessity of having a robust Content Security Policy (CSP) and how our current widget configuration might pose difficulties with your setup.

We appreciate your suggestions, particularly regarding the use of a nonce on widget initialisation, shifting from inline to class-based styles, the usage of non-statically generated IDs, and the provision of script/style hashes. These points have been documented and passed along to our engineering team for consideration in future updates and patches.

We strive to make our widgets as user-friendly and secure as possible. Your feedback plays a critical role in that ongoing improvement process. We will keep you updated on any developments concerning this request.

Let us know if you have any suggestions or feedback.

1 Like
3

We have hit the same issue today. It would be great if this could be implemented.