Bug 291734 – Shadow DOM inline/internal styles blocked by CSP

• Status: NEW
• Component: DOM

[Erik van der Plas]

We encountered an issue working on a web extension with a content script injecting a piece of UI on certain user-specified host pages. To render the UI, we create a Shadow DOM which is inserted into the host's body. We also include styles using the Emotion CSS-in-JS library, which inserts a style tag for styling our UI. However, in Safari, on pages with strict content security policies disallowing inline styles, the style tag is cleared along with the following console message:

> Refused to apply a stylesheet because its hash, its nonce, or 'unsafe-inline' does not appear in the style-src directive of the Content Security Policy.

We were wondering if this is desired behavior as we are operating inside the Shadow DOM: the content style is already guaranteed to be isolated from the host page style, and therefore one could argue that the CSP should not apply here. This also seems to be the case in other browsers. Either this is a WebKit bug or there should be an alternative solution, as I'd say this is a common usage pattern for web extensions. This concerns style tags inside the Shadow DOM, but perhaps also by injection into the host page by a web extension content script (as is also required for loading @font-faces https://stackoverflow.com/questions/63710162/how-to-load-font-face-in-dynamically-loaded-styles-of-web-component-with-shadow/63717709#63717709).

Looking forward to some insights, or a fix :)

Best, Erik

[Radar WebKit Bug Importer]

<rdar://problem/150015282>

[Kiara Rose]

you should be able to use `<style src='safari-web-extension://...'>` in the shadow DOM. it would require that resource to be a part of the `web_accessible_resources` in the manifest.

[Erik van der Plas]

Hi Kiara, thanks for you reply. I suppose you mean `<link src=...`? However, in this case, we use runtime generated styles instead of a fixed CSS file. Also note my remark on font faces, which currently necessitates injecting directly into the host page. I am not convinced that this provides a solution for our extension, but in general also a common browser extension usage pattern. The behavior is also inconsistent with other browsers.

[Frederik Riedel]

Hey Kiara!

I’m Frederik, we briefly met in the WWDC labs in Cupertino last month & I showed you our app “one sec” and the issue with the browser extension we have on pages like mastodon.social that Erik described above.

Would love to hear if you have an update on this.

Does the WebKit team consider this behaves as expected, or is this something that is planned to be fixed?

This would be great to know so we can correctly inform users about this & work on a workaround if necessary.

As additional information, this kind of issue does not reproduce on any other browser engine we’ve tested: Firefox, Chrome and Edge work fine intervening mastodon.social with one sec.

Thanks a lot for your great work & help!

– Frederik