"Unsafe attempt to load URL from frame"

[jonathantneal]

"Unsafe attempt to load URL from frame"

[tylertate]

I hit this problem as well when trying to serve an SVG sprite from a CDN. First, there is a fundamental problem: The use tag's xlink:href will NEVER load content from a remote server, even with CORS turned on. See the comments on this post.

There is a PARTIAL workaround: configure the CDN to handle CORS (CloudFront instructions, Heroku/Rails instructions) and then instruct svg4everybody to use AJAX to load the remote svg asset by setting polyfill to true: svg4everybody({ polyfill: true; });

While that will successfully load the remote resource, it won't stop the browser from throwing an error about "Unsafe attempt to load URL" for every instance of <use> on the page, which is ugly.

After going through all those steps I ended up just serving my SVG sprite directly from the server rather than from the CDN. Sometimes the simplest solution is the best.

[jpdevries]

I'm loving using <use> within <svg> to use svg icon sprites rather than icon fonts. I understand that there is currently no way to load them from a CDN even with CORS configured but what I am wondering is if there is a way to make use of some sort of onerror handler so that today we can attempt to load from a CDN, detect if it didn't work, and then load locally as a fallback.

[macouella]

For anyone who's wondering - https://css-tricks.com/ajaxing-svg-sprite/
The process described is:
a) Requesting the svg resource via XMLHTTPRequest
b) Appending the result to the body of the html page.

From the article:

var ajax = new XMLHttpRequest();
ajax.open("GET", "svg/sprite.svg", true);
ajax.send();
ajax.onload = function(e) {
  var div = document.createElement("div");
  div.innerHTML = ajax.responseText;
  document.body.insertBefore(div, document.body.childNodes[0]);
}

Just pasting it just in case anyone encounters the same issue!

[jonathantneal]

Yes, it’s because <use> is asking for the resource as a kind of document, which is a no-no. One way to work around this is trigger the polyfill in every browser and setup your CDN to allow XMLHttpRequests.

[jmmcduffie]

So, if I'm reading that correctly, this is a limitation of SVG and not of your library. Right?

[jalagrange]

Hello, I'm currently using AWS cloudfront and came up with this same issue. How exactly did you solve this?

[didoo]

Currently there is no workaround (if you want to use ). The only way to load an external SVG from a CDN is via an Ajax call (see how svg4everybody does, in its code).

[Rendez]

A solution might be to proxy-pass your image file using for example nginx, so that your file can be requested at your main domain.

[jonathantneal]

Without setting up your CDN to allow requests, this is a security feature (and in your case limitation) of cross domain requests, and not of SVGs or this library per say.

[jmmcduffie]

Thanks, @jonathantneal. We're going to try moving our assets to a subdomain to overcome this.

[Rendez]

For IE9 you can always use the XDomainRequest object.

[max]

@jmmcduffie I just tried moving the assets to a subdomain but still no luck. Did it work for you?

[DavidWells]

I'm running into the same issue.

What anyone able to solve?