Expand Security section with a demo and notes on sanitisation

https://github.com/styled-components/styled-components-website/blob/master/sections/advanced/security.js

This section contains some information on Security. Right now styled-components isn’t (and can’t reliably) sanitise user input. This is something we can add in v3 once we can differentiate between: properties, values, mixins, selectors in interpolations.

For now we should expand the Security section with two very important things that are lacking right now:

• How serious is this problem? (demo)
• How can you fix it quickly, if your app is vulnerable?

The first problem is that we need a demo that shows the user precisely how this happens. My idea is to just link to @jamesknelson’s CodeSandbox demo, or even article: https://codesandbox.io/s/llnzkwk0mz or https://reactarmory.com/answers/how-can-i-use-css-in-js-securely

The second problem is that neither our docs nor this article provide a solution, which seems to not be obvious to most. It’s critical that we give users the confidence to continue using interpolations for user input when it’s actually necessary.

For this we can link to CSS.escape which escapes CSS strings to make them safe for interpolations:

For this there’s a new utility in JS which is in the CSSOM proposal: CSS.escape (try it out! it’s in Chrome today afaik) https://drafts.csswg.org/cssom/#the-css.escape()-method

There’s a perfect polyfill for this method that we can use in the future by default, but for now we need to urge users to put it in their code themselves whenever they accept/interpolate user input for styled-components. https://www.npmjs.com/package/css.escape

Reference: https://github.com/styled-components/styled-components/issues/1105

[kitten]

@mxstbr Why not both? 😆 CSS.escape is nice because it’s the standard, and cssesc has some nice additions to it

[kitten]

If I’m not mistaken this issue (also since it’s 2 years old) has changed quite a bit in terms of the security scope we’re talking about.

On the client-side we’re using CSSOM insertion by default in production. This means that the risk of inserted CSS is lowered tremendously. In fact, all that could be inserted must be valid CSS.

So that means in production on the client-side, if you’re dealing with completely arbitrary user input (which of course is rare) you only have to deal with more being inserted than you expect.

Outside of strings in CSS that may mean escaping : and ; and curly braces for values for instance. Inside of strings maybe only quotes.

If you’re not dealing with arbitrary input then you should be fine.

If you’re dealing with SSR however you may want to ensure however that styles cannot output </style>

However that’s about it ✨

Edit: also, to define “arbitrary input”, if it’s client-side only and cannot be handed to another browser/user, you’re probably fine. If no XSS vulnerability can be triggered without the user’s input then you’re not running the risk of having the site changed for anyone but the person who’s seeking to change it, which is fine.

If you’re storing arbitrary input you may want to sanitise it when it’s stored instead to avoid extra cost when using styled-components.

Only when this doesn’t apply is when you should be worrying about it in the first place 👍