Issue with CSP rule "style-src 'self'"

[thorjarhun]

We use a Content Security Policy with "style-src 'self';" that causes violations when the braze sdk attempts to load the font awesome style sheets. We are working around the issue by using the doNotLoadFontAwesome configuration option but it would be great if the sdk were updated to be compatibility with this rule. While the current means of loading the styles is not supported, styles can still be added programmatically with our policy using alternative methods, though the easiest solution might be to give us the ability to specify a NONCE when we initialize the sdk.

[froodian]

Hi @thorjarhun

Thanks for reporting this, I'm glad you have a workaround for the moment but I agree we should handle this better internally. The nonce solution makes sense to me and sounds like it'll work, but just to make sure I'm understanding the problem space properly, when you say "styles can still be added programmatically with our policy using alternative methods", are there other potential approaches that we should potentially consider for loading the stylesheet from use.fontawesome.com?

Regardless, I'll put ensuring solid support for the style-src 'self' CSP rule onto our backlog.

[michaelcameron]

There are two separate issues. Font Awesome is the first issue, and can be fixed by using doNotLoadFontAwesome and then sourcing it differently.

The other issue is that the web sdk script creates an inline style element using document.createElement("style") that then gets added to the DOM. That style element will violate a CSP that does not allow unsafe-inline. There are a few ways around that 1) externalizing the CSS into a separate file and allowing that to be self-hosted 2) providing a hash of the CSS contents in the style-src CSP (but this will be sensitive to any CSS changes between releases) 3) providing a nonce that would be added to the style tag as an attribute (but this would require an initialization option similar to doNotLoadFontAwesome)

[froodian]

Thanks for the clarification @michaelcameron.

For the Web SDK's internal styles, we used to have a solution like 1 in place - at the time it required integrators to reference both the JS and CSS, which caused problems during integration and with upgrades (people not referencing the CSS correctly, version mismatches, etc), which is why we removed it. We could potentially avoid that specific problem by building in logic to have the SDK automatically load the CSS from our CDN unless instructed to use a self-hosted CSS file explicitly, but my concern would be that bundling the files separately and requiring the browser to make two requests introduces stability risk if one request fails - a nice outcome of bundling the CSS with the Javascript is 100% reliability on having the CSS if you have the JS (and therefore having a strong guarantee of never showing a user an unstyled in-app message). Loading the CSS from the CDN automatically would also be a breaking change for clients who are self-hosting the SDK and who have a significant number of users behind firewalls that block access to our CDN.

Solution 2 seems potentially viable but as you say it requires integration updates whenever the CSS changes, which seems undesirable.

All that to say, I agree with the initial assessment that the simplest solution is to modify the Web SDK to take a nonce via an initialization option and decorating the style elements for Font Awesome and the SDK's inline styles with that nonce. I'll work to get this prioritized as soon as possible on our end.

[froodian]

Hi @michaelcameron / @thorjarhun - we've just released Web SDK 2.4.0 which contains a contentSecurityNonce configuration option as suggested, and should hopefully resolve this issue for you. If you continue to experience issues when using this option, please let us know! Thank you for reporting this issue!