Built-in Icons: SVG Sprites + Radix Icons 🎉

[kentcdodds]

I'm excited to announce the addition of a process for SVG Icons!

Read all about it in the decision document and the icon docs.

Things look much more professional now 😅 Better than emoji for sure.

[kentcdodds]

Huge thank you to @kiliman for his help here and his support with rmx-cli!

[kentcdodds]

I don't know how this approach would be vulnerable to XSS.

[fivetwelve]

I shared this approach with someone on my team and they mentioned that there was feedback from our company's security or devops group that pointed to SVGs being a vector for XSS when used without an <img> tag. Googling nets a lot of reports about the issue but not so many resolutions. Such as:
https://rietta.com/blog/svg-xss-injection-attacks/
https://news.ycombinator.com/item?id=25349362

The issue has apparently been around even in 2016 at least. Here's a mention at Shopify where they resolve it by rendered the svg as a data string: https://hackerone.com/reports/1276742. They still resort to using as a src and not able to pass in props.

I did come across a possible remedy from GitLab which in turn is based on domPurify, which looks like a case of ensuring the hostname of the asset is approved. I apologize if none of this contributes much. I'm trying to learn more deeply about the options for resolution and still be able to use your SVG method.

Update: added link to GitLab

[kentcdodds]

But the svgs don't include script tags. They're not coming from users. These are coming from our own source code. There certainly would be danger if you reference user-submitted SVGs in this way, but we don't so we're not vulnerable.

[fivetwelve]

Okay, that's fair. I think I needed that sanity check. Vulnerability exists it seems with user-uploaded or third-party SVGs or cases where a hostname is outside your control or susceptible to some kind of intervention.

[fivetwelve]

Thanks for your feedback, Kent!