CSP 3 adds two new directives that supersede the style-src directive. These must be honored if present, with a fallback to style-src only if they are not.

style-src-elem specifically for <style> elements
https://w3c.github.io/webappsec-csp/#directive-style-src-elem

style-src-attr specifically for style= attributes
https://w3c.github.io/webappsec-csp/#directive-style-src-attr

The major motivation appears to be to allow inline style attributes (which don't support selectors) without allowing full arbitrary style that can change an entire page.

HI,

We are facing similar issue with style-src-attr. We have added a new CSP policy as part of apache configuration which blocks inline-styles at
style-src and allows only whitelisted hashes. But we allowed unsafe-inline at CSP level 3 on style-src-attr.

Everything works great on Chrome but FireFox blocks styles and those are not applied on the attribute.

As this is a very old thread. May I know if this issue is fixed ?
I have updated Firefox to latest but still same issue.

Thanks,
Amjad

Hi,

I am also facing the same issue. Mozilla Firefox is a browser which stands out among other browsers because of its security level en privacy protection. It is therefore surprising that the style-src-attr or style-src-elem directives are not available in Firefox browser.

When will these two subdirectives be implemented?

Thanks,
Bart

Setting this as a P2 for now, as the WebCompat report linked in this bug looks really broken, but the site generally still works.

Daniel, are you aware of other site breakage caused by Firefox not supporting this CSP directive?

I'm not aware of specific other sites that are broken, but it wouldn't be surprising if there are others since testing only in Chromium browsers seems to be fairly common. Up to now such sites would also be broken in Safari and the prominence of iOS means that often gets tested at least, so current breakage might be small. However, Safari appears to have support for these in their current technical preview so I expect it will get worse next year.

It is easy for a site to create a policy compatible with "old browsers" by making sure style-src exists and is the union of style-src-attr and style-src-elem. But it's also easy for those to get out of sync as a site is maintained. Rather than cramming both into one really long policy, it's better for sites to actually have two separate content-security-policy headers, and browsers will enforce both. For example:

Content-security-policy: style-src 'unsafe-inline' <sitelist>
Content-security-policy: style-src-elem <sitelist>; style-src-attr 'unsafe-inline' <sitelist>

For Firefox the second policy is a no-op (unknown directives are ignored), but it's still going to enforce the first. Chrome (and soon Safari) will enforce both but the stricter policy for -elem in the second policy will overrule the weaker first policy.

In addition to the above: the same goes for script-src, script-src-attr and script-src-elem directives. Inline event handlers like clickable buttons are blocked by firefox as the browser does not recognise the script-src-attr ('unsafe-inline') directive but only recognises the parent script-src ( 'self' with sha256 hashes for the scripts). The chrome browser is able to read the script-src-attr directive. There is a solution which firefox actually promotes. Move the inline event handlers to a javascript file so that the script (when properly hashed in the CSP) is allowed. This way, the script-src-attr directive is not required anymore. Use the addEventListener() method to register an event listener (for example 'click' or 'load') and implement this method in the javascript code.

(In reply to bart from comment #5)

In addition to the above: the same goes for script-src, script-src-attr and script-src-elem directives. Inline event handlers like clickable buttons are blocked by firefox as the browser does not recognise the script-src-attr ('unsafe-inline') directive but only recognises the parent script-src ( 'self' with sha256 hashes for the scripts). The chrome browser is able to read the script-src-attr directive. There is a solution which firefox actually promotes. Move the inline event handlers to a javascript file so that the script (when properly hashed in the CSP) is allowed. This way, the script-src-attr directive is not required anymore. Use the addEventListener() method to register an event listener (for example 'click' or 'load') and implement this method in the javascript code.

script-src-elem and script-src-attr were implemented in bug 1529337.

From comment 4:

Rather than cramming both into one really long policy, it's better for sites to actually have two separate content-security-policy headers

"better" is a personal opinion based on readability and maintainability. It can also help avoid header lines thousands of characters long in extreme cases—I've seen them!—since those can run into networking issues depending on what middleboxes are between the user and the site.

https://hg.mozilla.org/mozilla-central/rev/5caeea2c1f58

FYI Docs work for this can be tracked here: https://github.com/mdn/content/issues/20878

In this case pretty much just browser compatibility update and addition to experimental features page.