Allow 'strict-dynamic' scripts to inject styles

[vejja]

I am talking in the context of Javascript frameworks (e.g. React, Vue, etc.)
CSP is hard to implement in this context because these frameworks inject a lot of dynamic elements on the client side.

Fortunately, we have 'strict-dynamic', so if we allow the root script by nonce or hash, this solves a lot of issues.
But currently, one of the limitations of 'strict-dynamic' is that it can only delegate approval to other <script> elements.
And unfortunately, these frameworks insert a lot of <style> elements at runtime.

So, as it stands now, we have to resort to style-src: 'self' 'unsafe-inline' https:; for styles:

• 'unsafe-inline' is required so that the framework can insert inline styles
• 'self' https: and other name-based allowlists variants are required to insert external styles, because using a nonce or hash for external stylesheets that we know are legit would cancel 'unsafe-inline'

If a script has been allowed by nonce or hash, it is itself a secure context - therefore (unless I'm mistaken) any inline or external style that it decides to inject is legit.

Would it then be possible to extend the scope of 'strict-dynamic' to styles inserted by a secure script?
And maybe not only to styles but to any element by the same logic?

[bakkot]

This came up very briefly here:

'strict-dynamic' applies only to scripts and there is no equivalent for styles. It wouldn't be unreasonable to implement something similar for styles (it could help with resources loaded by stylesheets with an @import), but it would be a new feature request for CSP.

I would also like to see this.

[gregtalarico]

I think this proposal makes a lot of sense. If we are extending trust to a script via a nonce, then anything that script does should be trusted, including setting dynamic styles.

[vejja]

Hi @mikewest
I’d love to hear your thoughts on this one. Ready to provide any help that would be required, if you think useful.

[tsotimus]

I want to add my strong support to this proposal and provide additional context to emphasise its importance in modern web development.

JS/TS ecosystem context

The Rise of CSS-in-JS Libraries

CSS-in-JS libraries (such as styled-components, Emotion, MUI, vanilla extract and etc) are now integral part of the JavaScript ecosystem. These libraries generate <style> elements dynamically at runtime, enabling powerful features like scoped styles, theme management, and dynamic styling based on props or application state.

The Popularity of SPAs and the Challenges They Face

Single-Page Applications (SPAs) have become a pretty dominant architecture in web development, particularly with frameworks like React, Vue, and Angular. However, SPAs face unique challenges when implementing CSP due to their runtime-driven nature:

1. Nonce Incompatibility: Unlike traditional server-rendered apps, SPAs often do not have a server to generate nonce values for each request.
2. Hashing Limitations: Hash-based approaches require the styles to be known at build time, but when using CSS-in-JS libraries, styles are generated dynamically during runtime. This means they are unavailable during the build process, making hashes (almost) impossible

The outcome

Given these limitations, SPAs and CSS-in-JS libraries are often left with only two options:

• Introduce server logic to support nonce values, which contradicts the serverless nature of many SPAs.
• Use 'unsafe-inline', which compromises the security of the application and undermines the purpose of CSP.

I just want to make clear that the situation above is not rare by any stretch of the imagination and its actually very common among front-end dev teams.

Why Extending strict-dynamic works

By extending the scope of strict-dynamic to include styles injected by a secure script, CSP can evolve to support modern development practices. If a script has already been validated through a nonce or hash, it stands to reason that styles injected by that trusted script should also be considered somewhat secure. Especially if we are already allowing this script inject other scripts!

This extension would:

1. Bridge the gap between modern development practices and CSP implementation.
2. Enable secure and practical CSP policies for SPAs and CSS-in-JS libraries.
3. Reduce reliance on insecure fallbacks, improving the overall security posture of web applications.

Why I care

• I came across this issue whilst building a plugin for SPA's
• I care about security

P.S Sorry for the essay and thanks for reading!

[salceson]

Any updates on this? Was this at least discussed?

[vejja]

@tsotimus

Thank you for your excellent description of the issue that needs to be resolved.
I would like to add that even without using any CSS-in-JS library, all major frameworks will face serious issues.

For instance, VueJS has the native ability to bind styles dynamically

• In HTML templates via style attribute binding : see https://vuejs.org/guide/essentials/class-and-style#binding-inline-styles

<div :style="{ color: activeColor, fontSize: fontSize + 'px' }"></div>

<!-- This example is self-explanatory of what the UI/UX designer is trying to achieve
The average frontend dev team won't anticipate that CSP blocks the feature -->

• In CSS scoped styles via v-bind() : see https://vuejs.org/api/sfc-css-features.html#scoped-style-tips

<style>
.text {
  color: v-bind(color);
}
</style>

<!-- This example shows that CSP will block features in unexpected ways, based on semantics only
In fact, the exact same thing could be achieved by binding the "class" attribute directly
i.e. a direct class mutation such as <div :class="{ text }" /> on each candidate element won't be blocked by CSP
Here the frontend dev team tried to be clean and implemented separation of concerns and code deduplication
But CSP will block only because the class is mutated inside a style element, rather than directly in HTML --> 

In its current form, CSP will block both native syntaxes unless style-src: 'unsafe-inline' is used.

In essence, CSP is preventing any application made with VueJS, React, Svelte etc. to run properly in SPA mode.

For people who need to further understand why it happens:

1. SPAs cannot use nonce because by nature, SPAs generate static HTML pages that are delivered from a CDN. No server is available to generate and inject nonces.
2. SPAs cannot use hashes because as you can see in the 2 examples above, as soon as Javascript will try to update the reactive values, the content will change and therefore the hash will block the update

This is why we believe that strict-dynamic should be extended to styles.
In practice, it is the VueJS runtime which is trying to update the styles, so if the VueJS runtime was itself marked as secure at a higher level with strict-dynamic, we could then consider that any modification of styles that it is trying to do should also be permitted.