Remove support for data: URL in SVGUseElement

[shhnjk]

Request for position on an emerging web specification

Information about the spec

• Spec Title: Remove support for data: URL in SVGUseElement
• Spec URL: Remove support for data: URL in SVGUseElement w3c/svgwg#901

Design reviews and vendor positions

• Mozilla standards-positions issue: Remove support for data: URL in SVGUseElement mozilla/standards-positions#718

Motivation

Assigning an attacker controlled string to SVGUseElement.href causes XSS due to data: URLs. This also led to a bypass of Trusted Types in Blink.

Since Webkit does not support data: URLs in SVGUseElement and Mozilla's interest in unshipping, we think that it worth unshipping.

Therefore, we'd love to get official signal from Webkit.

Currently, the usage of data: URLs in SVGUseElement is about 0.0056% of page load in Chrome.

[annevk]

What makes <svg:use> special that it wouldn't be CORS-eligible, leading to nearly the same exploit? And if it's not CORS-eligible, why keep

A future version of this or another specification may provide a method of securely enabling cross-origin re-use
of assets.

in?

[shhnjk]

What makes <svg:use> special that it wouldn't be CORS-eligible, leading to nearly the same exploit?

IMO, the ability to import external script or html into current document has been only granted to places where script can be executed (i.e. script.src, import(), etc). AFAIK, SVGUseElement is the only place where we still allow this (through data: URLs), but there have been others which have been removed (e.g. HTML import).
I've also explained this in bit more details at w3c/trusted-types#357 (comment).

We believe that this also led to several other bugs in sanitizers and linters missing a check for this special case. (e.g. Sanitizer API)

And if it's not CORS-eligible, why keep

A future version of this or another specification may provide a method of securely enabling cross-origin re-use
of assets.

in?

I agree that we shouldn't allow cross-origin resources in SVGUseElement. I will follow up on this at w3c/svgwg#707.

[annevk]

Interesting, I thought foreignObject was similarly afflicted, but according to SVG 2 and some testing it's not. I think I agree then that it's better to keep this same-origin.

I suggest we mark this as "position: support" on January 6 given the holidays.

[shhnjk]

Sounds good! Thank you!

[hober]

Closing as we've identified our position.