Referencing SVGs through USE from other domains

[waterplea]

Currently, trying to host SVGs with symbols on CDN and then using them on your page through USE tag to allow color changes with currentColor results with error: Unsafe attempt to load URL. There is a bug for chromium suggesting it should follow CORS policies providing ability to allow such references:
https://bugs.chromium.org/p/chromium/issues/detail?id=470601

There was a suggestion to add crossorigin attribute to USE but it seems that specs only define it on IMAGE or SCRIPT:

https://svgwg.org/svg2-draft/linking.html#processingURL-fetch

Please have a look at it. Seems to me that it would be a lot safer to use SVGs like that rather than loading them with network request and inlining in the page which is a current workaround if you want to control the color.

[AmeliaBR]

I agree that this is important. It is a significant limitation for SVG the crossorigin use references aren't supported. I think you make a good point, that this encourages less safe practices by authors.

When the crossorigin attribute was originally added to SVG, <use> was included. It was removed in 2015 because of concern about the details about how <use> imports should work. But even then, the plan was to add it back in eventually. (See discussion minutes & resolution)

Many of the issues that were brought up in that discussion (about how the use element shadow DOM model should work & how external files should be parsed) have since been resolved (although the current spec text doesn't reflect all the resolutions that have been made in other issues). So it may be worth reconsidering.

[waterplea]

I'm not a security expert, I tried USE with external SVGs on the same domain and it seems that scripts are not run, neither event handlers like onclick trigger and other basic malicious scripting I could think of. I realize there is more danger there that I do not know about, but like I said, people currently work around this by simply requesting SVG source and inlining it into the page and I doubt many of them run it through DOMPurify or something. So even if it might be a not that safe practice, to achieve the same effect people most likely turn to an even more dangerous solutions.

Glad to see it's not dismissed completely, hope you can think of something!

[css-meeting-bot]

The SVG Working Group just discussed Referencing SVGs through USE from other domains, and agreed to the following:

• RESOLUTION: Add cross-origin attribute to the <use> element in a current or future spec
• RESOLVED: Add cross-origin attribute to the <use> element in a current or future spec
• RESOLVED: Add the cross-origin attribute to the <use> element to SVG 2, and mark it at-risk
• RESOLVED: Request implementation feedback about the cross-origin attribute to the <use> attribute

The full IRC log of that discussion

<myles> Topic: Referencing SVGs through USE from other domains
<myles> GitHub: https://github.com//issues/707
<myles> AmeliaBR: Should we add a cross origin attribute to the use element.
<myles> AmeliaBR: Right now, none of the browsers support <use> references to cross-origin files. But they do support it to the same origin.
<myles> AmeliaBR: When SVG introduced the cross-origin attribute for <image> and <script>, it was added to <use> but it got pulled back because it was unclear how it would work with shadow dom, and how that would affect cross-origin. I think that is cleared up now. The way we agreed that <use> should be a closed shadow dom where you can't access the internals
<myles> krit: I don't think we have consensus on that
<myles> AmeliaBR: I thought we agreed? I can dig up the issue
<AmeliaBR> https://github.com//issues/363
<myles> AmeliaBR: Everyone agrees.
<myles> AmeliaBR: But! Neither of those really make a difference. All those complications would be the same. The use case brought up in this new issue makes a good point, that because cross-origin <use> isn't supported, the workaround that authors have to use is to fetch the cross-origin file with script, and then inject the markup directly in their page, because this is less-secure than <use> cross references, we say things like "don't run scripts"
<myles> krit: But if there is a less-secure method, then providing a more-secure method isn't necessarily a win for the users
<myles> AmeliaBR: There are two risks. 1) Allowing the current webpage access to the content from the other domain, but I'm not suggesting that we should allow free origin; it should be based on CORS
<myles> AmeliaBR: This is security for the webpage author when you're referencing a 3rd party domain, where the content on that 3rd party domain might change.
<myles> AmeliaBR: We get a little bit of extra security if the page author opts into it. Like CSP.
<myles> AmeliaBR: Also, it's easier for the author (less lines of code)
<myles> krit: We already define cross-origin attribute for other elements. Specification-wise, it wouldn't be a big deal to add it. Do you think implementations would implement it? Or should we move it to SVG 2.1.
<myles> AmeliaBR: I'd like to resolve that we'd like to add this, but then ask implementors whether they think it can come in the short term or whether it should be delayed
<myles> krit: Any concerns for adding the cross-origin attribute to <use>?
<myles> <silence>
<myles> RESOLUTION: Add cross-origin attribute to the <use> element in a current or future spec
<myles> RESOLVED: Add cross-origin attribute to the <use> element in a current or future spec
<myles> krit: Since we resolved on that part, we can at least have a note with our intentions into SVG 2.
<myles> AmeliaBR: Sure. We can add a note and open issue, requesting implementor issue
<myles> krit: That's part two. For now, let's resolve on a note.
<myles> <some general discussion about the merits of a note vs normative text>
<myles> AmeliaBR: We should start the request for feedback right away, on the issue therad.
<myles> *thread
<myles> RESOLVED: Add the cross-origin attribute to the <use> element to SVG 2, and mark it at-risk
<myles> RESOLVED: Request implementation feedback about the cross-origin attribute to the <use> attribute

[AmeliaBR]

@fsoder @longsonr @litherum Consider this a request for feedback (please pass on to whichever colleague can best answer):

How easy/difficult would it be to make <use> cross-origin, with crossorigin controls? The default behavior (no attribute) would still be to block cross-origin requests. Processing of the external file would be the same as for same-domain external <use> references.

[longsonr]

I'm waiting on other implementers to do image and FEImage. I assume they'd be easier.

Not sure we'd implement crossorigin for <use> given the existence of open redirectors.

[AmeliaBR]

the existence of open redirectors.

I'm not sure what you mean. In the sense that a <use> reference to one file can then trigger references to other files?

[fsoder]

It shouldn't be too difficult if there are no additional restrictions to consider (integration with CSP?).

[waterplea]

So what is the next step now? Chromium bug to support it is on hold until specs are established. @longsonr you haven't clarified what you meant by dangers of open redirectors.

[longsonr]

See https://bugzilla.mozilla.org/show_bug.cgi?id=628747