Material-ui: JSS limitations with Content-Security-Policy?

Created on 8 Jul 2016  路  9Comments  路  Source: mui-org/material-ui

Problem description

When using a Content-Security-Policy of "default-src 'self'" I get errors from Chrome and Firefox that the code violates the CSP:

Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-D8Sj8qhd4FvnVwN5w9riiArwsqYOEwHolv228Ic6Vqk='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

It seems to be from EnhancedButton.js function injectStyle() where an inline-CSS are added to document.body:

    // Remove inner padding and border in Firefox 4+.
    var style = document.createElement('style');
    style.innerHTML = '\n      button::-moz-focus-inner,\n      input::-moz-focus-inner {\n        border: 0;\n        padding: 0;\n      }\n    ';

    document.body.appendChild(style);
    styleInjected = true;

Commenting out document.body.appendChild removes the CSP violation message. Would it be possible to add the styling in another way to not violate the CSP?

Steps to reproduce

Add HTTP header "Content-Security-Policy" with value "default-src 'self'" and use a EnhancedButton on the page.

Versions

  • Material-UI: 0.15.1
  • React: 15.2.0
  • Browser: Chrome 51.0.2704.106 (64-bit), Firefox 47.0.1
discussion

Most helpful comment

This is quite unfortunate behavior, as it requires hacking around this if wanting to have strict CSP rules in an app (and no errors in the browser console). The piece of code seems to date back to almost two years, and seems to be the only case where this approach is being used, I'd imagine there is a better way to do such reset within this lib.

All 9 comments

This is quite unfortunate behavior, as it requires hacking around this if wanting to have strict CSP rules in an app (and no errors in the browser console). The piece of code seems to date back to almost two years, and seems to be the only case where this approach is being used, I'd imagine there is a better way to do such reset within this lib.

FWIW, this can luckily be "fixed" via adding a specific hash describing this inline style to style-src as suggested by Chrome DevTools, for instance:

style-src 'self' 'sha256-D8Sj8qhd4FvnVwN5w9riiArwsqYOEwHolv228Ic6Vqk='

Works as far as nobody touches that resulting piece of CSS (also whitespace matters there).

@harriha Thanks for the tips! We changed our styling approach with the next branch removing the need for that hack. I'm not sure how the CSS-in-JS solution (JSS) performs regarding CSP. Any clue?

@oliviertassinari Good to hear, cheers! And indeed, this wasn't the only CSP issue I eventually ran into (first it seemed this was the only one affecting my project), CSS-in-JS in general turned out to be quite problematic in this regard. Thus, even though I managed to find a workaround for this particular issue, had to stick with the unsafe-inline anyway for the time being.

I adding @kof to the conversation has he might have some insight on the Content-Security-Policy implication of JSS and couldn't find any reference on the repository.

Interesting problem, didn't research it yet. Please create an issue on JSS issue tracker if there is anything we can do over there to prevent it in JSS.

Ah, must clarify one thing: strict CSP is not a problem with all CSS-in-JS approaches, only with those which rely on inline styling or adding/removing <style> tags runtime (afaics, I don't claim to be an expert on CSP details). I'm not familiar with JSS (yet) and missed that reference in Olivier's original reply, thus the slight confusion here. Haven't realized this project is moving away from inline styling, which is very nice from CSP point of view as well.

What comes to CSP in the JSS project: being compatible with strict CSP would get thumbs up from me at least. Not sure what would the best way to create an automated test setup for this, but luckily browsers are helpfully recording the violations to the console at least - and can send them to server as well if the report-uri is set. The report-only version might be worth considering in such test setup if taking this route.

All cssinjs either do inline or add/remove style tags. In JSS you could write a plugin which could yeld a warning + remove CSP unconform property so that the entire sheet continues to work.

The issue was resolved with https://github.com/cssinjs/jss/issues/559. I'm upgrading JSS to v9.3.0. You can use a nonce with this version. window.__webpack_nonce__ = 'what you want'.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

FranBran picture FranBran  路  3Comments

rbozan picture rbozan  路  3Comments

finaiized picture finaiized  路  3Comments

sys13 picture sys13  路  3Comments

revskill10 picture revskill10  路  3Comments