New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 34 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Issue 470601: SVG <use> element blocking cross-domain requests, with no option to use CORS

Reported by, Mar 25 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Create a page on `` with SVG such as the following:

      <use xlink:href=""></use>

2. Place `some.svg` on, with response header:

    Access-Control-Allow-Origin: *

What is the expected behavior?
The SVG <use> reference renders the SVG fetched from ``.

What went wrong?
"Unsafe attempt to load URL from frame with URL Domains, protocols and ports must match."

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? No Firefox, Safari tip

Chrome version: 41.0.2272.89  Channel: stable
OS Version: OS X 10.10.2
Flash Version: Shockwave Flash 17.0 r0

It's not really clear from the spec (e.g., that there's any reason for this not to work. It does make sense that this request would be blocked without CORS headers (even though it's not clearly specified), but I would at least expect it to try CORS before simply blocking the request.

Comment 1 by, Mar 26 2015

Labels: Needs-Feedback
joel@ -  Could you please provide sample html file where we can look in to this issue for further assistance.

Comment 2 by, Mar 26 2015

Content Security Policy (CSP) may prevent loading such resources.

@mkwst: are there any tests for this particular scenario in blink?

Comment 3 by, Mar 26 2015

@brajku: Kind of. It's not simple to provide a full reproduction, because doing so (at least relative to the way I've reported it) requires controlling HTTP response headers to test the CORS case.

I've created the following example, which gets you 90% of the way there. To test it with CORS, you'll need to take `svg.svg` and run it in your own HTTP server on another domain, with `Access-Control-Allow-Origin: *` in the response.

@e: That's what I would expect. It's hard to be sure from the spec (afaict, CSP/CORS don't get discussed much, if at all, in specs like svg and xlink), but I was under the impression that vendors were generally trying to use CORS as a standard workaround for CSP-related issues.

Comment 4 by, Mar 26 2015

Labels: Cr-Blink-SVG
That's not a CSP issue, that's the "access denied" message you'd get if you couldn't request the resource. Adding pdr@ for some SVG expertise.

Comment 5 by, Mar 26 2015

Labels: -Needs-Feedback
Status: Available
@Joel, you're way ahead of implementations here, and probably specs too. I agree that this is a bug and we should fix it as you've described by having CORS apply to SVG's xlink references. We don't have any tests or code for this today.

A workaround today is to use a preprocess step to bundle external requests into a single file.

@ed, would you like to investigate this area? is another example but for CSP. As far as I'm aware, this is uncharted territory.

Comment 6 by, Mar 27 2015

Status: Assigned
I'll take a look.

Comment 7 by, Mar 27 2015

Right now all* browsers block <use> from loading anything cross-origin.

My suggestion is to add a 'crossorigin' attribute on <use>. I can propose this to the SVG WG, assuming we all agree that we should allow opting in to using CORS here.

Draft CL:

* Tested in Firefox Nightly, IE11 and Opera/Chrome dev.

Comment 8 by, Apr 15 2015

@e...: That sounds perfect for our purposes, and matches the CORS pattern used elsewhere, so I'm quite supportive. Let me know if you need any support on the mailing list from people with software affected by this.

Comment 9 by, Apr 16 2015

I've put it on the SVG WG agenda, but we've not yet had an opportunity to discuss it. Anyway, the thread is here:

Comment 10 by, May 8 2015

Labels: -OS-Mac OS-All
Handing this over.

Comment 11 by, Jul 10 2015

Labels: -Cr-Content Cr-Blink

Comment 12 by, Oct 16 2015

Labels: -Cr-Blink

Comment 13 by, Feb 25 2016

Is there any movement on this issue? It's crippling our attempt to host SVG packs on our CDN and load them in cross domain using <use xlink:>.

Comment 14 by, Feb 25 2016

It's currently blocked on "spec issues" I'm afraid: (see the "Blocked on"-link for further context.)

Comment 15 by, Mar 17 2016

Is there a way or hack to go around this issue?

Until the spec is finalized, that is?

Comment 16 by, Mar 17 2016

I'm afraid not. (Well, not client-side at least - if so that'd be a bug...)

Maybe somewhat tongue-in-cheek, but I think the best you can do is make more noise about it (just not here =))

Comment 17 by, Apr 24 2016

no perfect solution but a temporary workaround would be to ajax the svg and inject it into the DOM. That way you just need to manage ajax CORS.
Also it adds the benefits to work with ie and css rules on shapes.

We shouldn't expect any official/clean way to do that until some years....

Comment 18 by, Nov 22 2016


Comment 19 Deleted

Comment 20 by, Aug 8 2017

Anything new on this one? I'm having a moderate problem with this one

Comment 21 by, Aug 8 2017

AFAIK there's no "news" here. To reiterate what I wrote in my last comment - feel free to make noise about this in a forum with wider circulation than this.

Comment 22 by, Oct 9 2017

Is there any progress on this?

Comment 23 by, Oct 9 2017

Sadly no (see previous comments.) Maybe I should set "ExternalDependency" on this one...

Sign in to add a comment