CSP compatibility

[cjcenizal]

AFAICT, we just need to remove inline style attributes. @epixa @bevacqua Is there anything else we need to do to make EUI CSP-compatible?

[bevacqua]

Well, that boils down to the rules set by the consumers of EUI. No inline style, no eval is about the baseline. Note that no inline style ends up being pretty hard to enforce, for example: the code editor in EUI has no built-in support for CSP unless the consumer enables 'unsafe-inline', which as the name may have you guess, is not ideal. Nevertheless, we have that rule turned on for now in Cloud. Though I'm hoping that can change at some point, not really holding my breath.

• When it comes to images, for instance, Cloud only accepts data: urls or 'self' (same-origin)
• We accept no external fonts atm, but EUI doesn't have any.
• Requests: for the most part, we don't allow external requests, so any and all requests should be configurable by the consumer, same for script source

[epixa]

I think EUI needs to be as conservative in its CSP tolerances as our most restrictive CSP in Elastic products, which right now is Cloud and will soon be Kibana.

@cjcenizal I recommend figuring out the most restrictive CSP possible on EUI today by adding the CSP header to the EUI docs. The current target in Kibana is elastic/kibana#2873 (comment), though we're a ways off from that. However, our goal is to disable inline scripts as soon as humanly possible, so that's probably the most critical thing to sort out in EUI.

[cjcenizal]

Thanks you two! Very helpful.

[snide]

I don't know much about CSP, but I know there's a couple places where we need to set styles through JS and I can't think of a way to do it through pure css classes alone.

• Tooltips and similar "where am i in the window" components require it for positioning
• Accordions, mobile nav and others have height/width calculations that apply matching styles
• Applying a background image onto something is pretty common.

Is there some place you all recommend I can read up on some of these rules. Meeting 100% no-style tags will be pretty hard to do with our feature-set.

I was curious how this kind of stuff would effect CSS-IN-JS libs like styled components. Looks like they set webpack_nonce to pass a crypto along with the style tags? Is something like that an option for when we absolutely need it? Again, I have very little knowledge of this stuff, so just asking questions.

styled-components/styled-components#887

[bevacqua]

Yes, nonce would be better than inline for sure. Note that injected style tags are not inline, only style attributes are inline

…

On Mar 13, 2018 09:18, ***@***.***" ***@***.***> wrote: I don't know much about CSP, but I know there's a couple places where we need to set styles through JS and I can't think of a way to do it through pure css classes alone. - Tooltips and similar "where am i in the window" components require it for positioning - Accordions, mobile nav and others have height/width calculations that apply matching styles - Applying a background image onto something is pretty common. Is there some place you all recommend I can read up on some of these rules. Meeting 100% no-style tags will be pretty hard to do with our feature-set. I was curious how this kind of stuff would effect CSS-IN-JS libs like styled components. Looks like they set webpack_nonce to pass a crypto along with the style tags? Is something like that an option for when we absolutely need it? Again, I have very little knowledge of this stuff, so just asking questions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#506 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5BlUo-awzOvhoU6WMgYwSZaGqryMAjks5td_E5gaJpZM4SoClg> .

[alexbrasetvik]

sha256-[digest] would be preferable to nonce, if possible :)

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[chandlerprall]

We still want to track this.

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[github-actions]

❌ We're automatically closing this issue due to lack of activity. Please comment if you feel this was done in error.

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[cee-chen]

Hi all - I'm closing this issue due to age and Kibana apparently no longer pursuing the removal of inline styles (elastic/kibana#135469 (comment)).

Our reasoning is much the same as the above linked comment - inline styles are absolutely necessary for things like virtualization and dynamic positioning, as well as wildcard consumer content like dynamic colors. Using Emotion/CSS-in-JS is not a valid replacement as Emotion generates a new stylesheet/class name for each permutation of each CSS value, which leads to potentially infinite styles/class names generated on the page and has massive performance implications.

If you disagree, feel free to re-open this issue or leave an additional comment.