-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CSP] Issue with inline-style and Content Security Policy #19938
Comments
Generally I think we shouldn't use inline styles to begin with since they make customizing harder. So ideally we wouldn't use inline styles at all. In the meantime we should add this notice to the docs. |
This concern seems important for the use of the components in high demanding environments, e.g; #13364 coming from SnapChat Inc.? However, from our issue history, most developers seem to loosen the CSP for it. We do have a couple of components that rely on inline style:
Wow, ok, actually, it's much more than I thought. I think that it would be interesting to explore:
|
Thanks for the input @eps1lon and @oliviertassinari . I'll loosen the CSP in my application for now, but exploring the removal of all inline style attributes would be great and would be something I'd support. |
Just coming here as I was surprised to find out I still had CSP errors after following the docs: https://mui.com/material-ui/guides/content-security-policy/ It looks like the docs were never updated as suggested, so I opened a PR. Hopefully, someone has an updated list of the "non-csp" components #21479. |
https://developers.google.com/web/fundamentals/security/csp/#inline_code_is_considered_harmful makes a case in favor of removing all inline style. |
@razor-x It seems that we have lost your contribution (#21479) along the way in v5: https://mui.com/guides/content-security-policy/. There are no more mentions of inline-styles and what needs to be done to handle them. We will also likely need to update the guide for emotion, our new default style engine for v5. |
@oliviertassinari just happen to be checking in on the progress towards Material UI v5 and remembered about this update. Ideally in v5 CSP would be fully supported by all the hard work done on switching everything to emotion 🤞🏻 . That said, I do believe my update to the docs in #21479 should have been pushed to the v4 docs and not bumped to v5. After all, my original goal with that update was to save time for any CSP users on v4 by letting them know of this edge case. I'm sure there will still be quite some time before all v4 users are moved to v5, so I'd like to get that back in if possible. Best. |
This comment was marked as spam.
This comment was marked as spam.
Multiline |
This comment was marked as off-topic.
This comment was marked as off-topic.
Bigger picture 2¢: Why wasn't CSS-in-CSS the default option? If CSS-in-JS wasn't a trend, we wouldn't see these issues popping up that require non-trivial workarounds. From my fresh-to-MUI viewpoint, this feels like it's bordering on bug not feature territory. |
@toastal The issue we track here is the use of inline-style. For example, if we consider: material-ui/packages/mui-base/src/TextareaAutosize/TextareaAutosize.js Lines 171 to 177 in 3aa5918
How do we replace this to be compatible without CSS-in-CSS vs. CSS-in-JS is not really a variable on the problem faced, at best CSS-in-JS could be a solution because it allows dynamic values. There are some discussions about this root issue in the standard working group, e.g. w3c/webappsec-csp#45 but I couldn't find really anything concrete to help. The option to use CSS-in-JS in the above example would mean that we should add to the unstyled component a dependency on a styling library, e.g. emotion, IMHO, it doesn't fly. rrweb-io/rrweb#816 (comment) is encouraging. It suggests that approved JS scripts can use the CSSOM API so some of this list #19938 (comment) could be solved. If anybody has the bandwidth, feel free to dive deeper. I suspect that there are components that we won't be able to migrate, hence it would be great to document this problem in https://mui.com/guides/content-security-policy/. |
I wonder if this library can take a similar approach to what Next.JS does to solve this issue: hoist the dynamic CSS into a Note that this approach shifts some security responsibility to the library that's inserting the dynamic CSS into the nonce-having It's probably going to require a fair amount of work to migrate all of the current inline styles into hoisted dynamic |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
also interested in knowing if there are any updates to this. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@oliviertassinari Not sure if the issue is related to my setup or not, but for some components that rely on inline style such as textField, the style attributes are missing on SSR. I'm facing a style mismatch between SSR and CSR after hydration. Maybe they are being added at a later stage after rendering is done? |
I think some dynamic styling is unavoidable, in the case of images. When you want to provide a pleasant loading experience you need to tell the browser what the aspect ratio is, and if you have a lot of images that means a lot of possible aspect ratios. Currently I pass the ratio as a CSS variable in a style attribute on the wrapping component. How to solve this, especially when you have a SPA that needs to dynamically insert images? |
Any updates on this? We are also blocked from using material UI for our project because of strict CSP policies mainly unsafe-inline. |
I created a reproduction with TextareaAutosize: https://codesandbox.io/p/sandbox/throbbing-browser-rkms3j?file=/next.config.js:33,18. As for solutions,
import * as React from "react";
export default function UnstyledTextareaIntroduction() {
return (
<div
style={{
"--foo": "bar",
}}
>
Hello
</div>
);
} doesn't work, not unless w3c/webappsec-csp#174 makes progress.
|
The documentation should be more clear. In my case My workaround is to use |
not sure why this is an issue when emotion is available. Isn't the OP code trivially css={css`
overflow: ${scrollerStyle.overflow};
${!visibleScrollbar
? (vertical
? `margin-${isRtl ? "left" : "right"}`
: 'margin-bottom') + `: ${-scrollerStyle.scrollbarWidth};`
: "" }
`} ? |
Can we please remove inline styles entirely? What prevents us from using CSS modules or plain old classes? That would simplify CSPs and allow Web applications to be less lenient with security. If we add a nonce to |
Agree, inline styles break SSR as well. |
We've dropped MUI in favor of https://github.com/rmwc/rmwc |
Does rmwc allow to pass CSP without 'unsafe-inline'? |
@saislam10 we extract all static inline styles known at build time. There doesn't appear to be a runtime component so far, so I'd be inclined to say yes. |
* Content-Security-Policy: add strict csp headers and use a nonce * Content-Security-Policy: add iiit main website in iframe whitelist * Fixed some icons are not loading * Allow icons to load from different sources * Minor Variable name change for better understanding * Redirect to the correct url between clubs and student-bodies * Simplify Gallery Images Bugger View, and added loading for images Helps in Google Indexing, as otherwise it treats /gallery and /gallery?img=index as different pages * Reduce showImage function * placeholder animation added for the images. * Minor change * Apply Prettier Formatting Fixes * handle merge conflicts: when rebasing the scp * Enable styled components * Use unsafe-inline with styles (mui/material-ui#19938) * csp: add unsafe to specific style --------- Co-authored-by: Bhav Beri <[email protected]> Co-authored-by: Bhav Beri <[email protected]> Co-authored-by: dileepadari <[email protected]> Co-authored-by: bhavberi <[email protected]>
According to the documentation, to support the CSP header, a nonce needs to be added to the style-src directive (https://mui.com/material-ui/guides/content-security-policy/). However, a number of Material-UI components make use of inline style attributes (e.g. Tabs -
material-ui/packages/mui-material/src/Tabs/Tabs.js
Lines 768 to 773 in 5c96f3c
So generally for Material-UI as I see it, I think one of two things are needed:
What do you think? I did an issue search and found this (#13364) suggesting that Material-UI as a whole allows inline style attributes and thus are happy with necessitating a non strict CSP setting. Is this still the case and we're happy with what this means for CSP?
Related:
The text was updated successfully, but these errors were encountered: