291734 2025-04-18 01:12:21 -0700 Shadow DOM inline/internal styles blocked by CSP 2026-02-28 11:55:54 -0800 1 1 1 Unclassified WebKit DOM Safari 18 Mac (Apple Silicon) macOS 15 NEW InRadar P2 Normal --- 1 erik.vander.plas webkit-unassigned cdumez frederik.riedel kiara_rose rniwa webkit-bug-importer wilander oldest_to_newest 2111764 0 erik.vander.plas 2025-04-18 01:12:21 -0700 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 2113053 1 webkit-bug-importer 2025-04-25 01:13:17 -0700 <rdar://problem/150015282> 2123027 2 kiara_rose 2025-06-11 10:32:01 -0700 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. 2123028 3 erik.vander.plas 2025-06-11 10:38:17 -0700 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. 2129992 4 frederik.riedel 2025-07-14 15:19:37 -0700 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 2185867 5 frederik.riedel 2026-02-28 11:55:54 -0800 Hello everyone, just wanted to let you know that this bug still reproduces on Safari 26 (macOS) throughout the latest beta of Safari – blocking our “one sec” Safari extension from working properly on many social media websites (e.g. mastodon.social). Is there anything we can help with get this addressed? Thanks a lot and have a nice day! – Frederik