Though it is a security issue it should be made public.

Agreed, This falls into the category of "security feature".

mkwst@ - do we want to try this?

I would not be sad if we treated SVG documents as having an opaque origin, but it's not clear to me what the impact would be on legitimate usage. "Interactive" might very well mean "requires a user to be signed-in." *shrug* It might be the case that your intuition is correct, homakov@, but I don't know enough about the ecosystem to make a decision.

CCing pdr@ and fs@, who know more about SVG than I do. We can probably skim through HTTP Archive as well to see what current usage looks like.

Not claiming I know how everyone uses SVG, it's not that popular. For most people it's a surprise it can have JS scripts. 

Even if there is marginal number of people enjoying shared origin benefits, they could use it with some opt-in header, I guess?

Putting them into an opaque origin also means that scripts can't access the svgdocument from the outside anymore, eg document.open() won't work or any other kind of interaction

For the top-level browsing context it would hopefully be unproblematic. For nested browsing contexts it seems extending 'sandbox' to also apply to <object> (and <embed>.) We already do have an even more locked down way of embedding though, which is <img>.

If compatibility is main concern, here is how we can do it gracefully:

1. If SVG is rendered on Origin1 using object/embed and served from same origin1 - let it run with same origin

2. Top-level context or if parent domain has different origin - use opaque origin

3. If served with <img> - switch off scripts entirely.

I would like to strongly disagree with this assumption:

"It's very unlikely anyone ever had origin-specific code in their SVG files for legitimate reasons - scripts are only there to make the image more "interactive". "

SVG code needs to run on the correct origin in order to AJAX data files for data visualizations.  It is also often required to load web fonts.  And of course, it is required for scripts to communicate between the interactive SVG and the host HTML page.

Yes, most interactive SVG these days is now done inline in an HTML document, but there are still many reasons for wanting to use a separate SVG file embedded as an <object>. 

If authors are serving SVG as interactive objects, they are intentionally turning JavaScript on.  If you want to restrict certain JavaScript functions, you have all the same sandboxing options as for iframes (where sandboxing is supported).

The security concern comes from SVG served as an image by the web page developers (JavaScript off, additional file fetching off, inert and secure), but then opened in its own tab (suddenly fully functional, including AJAX to the server origin).

If you are allowing non-technical content creators or end users to upload SVG, this possibility therefore creates all the same security concerns as allowing them to upload complete HTML files.  You either need to sanitize the content, or quarantine it on a sub-domain that does not share any private information, or you need to use Content Security Policy headers where supported, and serve fallback content (e.g., PNG snapshots) to older browsers that don't support CSP.

Of course, what most sites chose to do is to not allow end-users to upload SVG.  I would love to see browser and server developers make it easier to create secure SVG servers, for web developers who only want SVG as an image format.  But not at the cost of disabling full SVG functionality for devs who are using it that way.

> I would like to strongly disagree with this assumption

I am happy to change my view, if you say SVG badly needs same origin maybe you/anyone can point to some website currently using it? 

What do you think of graceful sandboxing offered in Comment 8? That would break less common embeddable svg, example https://jsfiddle.net/gmsg941r/ - still fixable.

> this possibility therefore creates all the same security concerns as allowing them to upload complete HTML files

That's exactly the problem! No one thinks of SVG (image format) as second HTML - let's admit we failed at naming it. It's not like we upload a .PHP file... 

Cross ref - https://github.com/w3c/svgwg/issues/266

I would be fine with enforcing new executable MIME too, either way something must be done.

While I wish we could go back to 1999 and fix the misleading name/mime-type, at this point the best move forward is better education.

HTML has a misleading MIME-type too, but everyone knows that text/html isn't plain text, it's an executable file with same-origin access privileges.

Regarding the proposal from Comment 8:

I'm not sure what your fiddle is supposed to demonstrate.  If it is that arbitrary scriptable SVG can include nuisance code like alert(), the solution is a sandbox attribute:  https://jsfiddle.net/37z7eLmw/. If your concern is that the JSFiddle is revealing the sakurity.com cookie, that is misleading: it is revealed to the end user, but not to the embedding domain's JS code.

There is no security concern from embedding cross-origin interactive SVG; browser cross-origin restrictions prevent information cross over, and is supported universally, and HTML sandboxing prevents nuisance scripts and phishing re-directs in modern browsers.

Also, to clarify: scripts *are* turned off completely when an SVG is embedded as <img>, and always have been, as are additional file fetches. 

The issue is same-origin file access, particularly when the file is viewed directly, without the restrictions imposed by the surrounding page (<img> or a sandbox attribute).

This is only a concern for the domain that is hosting the SVG, not for another domain that is embedding it.  However, your proposal would prevent the cross-origin embedded SVG or stand-alone SVG from accessing asset files from its own origin, without any CSP instructions from that server to do so.  In addition to breaking any site that uses SVG as a stand-alone file, this would mean that you would not be able to embed fully-functional SVG on a web page of a different origin.  This would break SVG for anyone using a separate sub-domain to isolate SVG assets from the main web page domain (which is currently one of the simplest approaches for dealing with same-origin security risks).

(Note: by break SVG, I don't just mean AJAX-ing data files. Lots of asset files used in SVG are only supported if they are on the same origin; fonts and <use> cross-references are the most common.)

I don't do enough big production work to have an example to link to, but I will encourage members of the SVG development community to weigh in.

Fiddle is demonstrating nothing actually, only an example of cross-origin embedded SVG. 

I agree breaking such use case isn't great. I wish there was a middle ground between same origin and opaque origin - when you can access all same origin resources but have no access to localStorage/cookies - something like unauthed CORS for everyone by default. 

That unfortunately does not exist and cors requests are too restricted for no reason :(

There is a security problem here, though I have not heard of a real exploit using SVG, only that it's a bee in the bonnet of some security-minded folks (perhaps I missed some incident?).

I generally agree with Amelia on all her points. I'm sympathetic to Homakov's concern, but their solutions don't seem quite appropriate to me.

I would like to find a way to allow SVG to be uploaded and trusted more, in a simple way. I wonder if there could be an additional SVG MIME type, application/svg, that would allow unfettered script execution and access for SVG files, while image/svg+xml could have opaque origins.

This change would also break SVG filters that use external resources via <feImage>, like piping it into <feDisplacementMap>. And currently, Chrome doesn't allow data: URIs for that, since it hasn't implemented all of the Filter Effects security specifications.

There was a proposal for a sandboxed MIME type for HTML (text/html-sandboxed) but it didn't take off.

Commit that dropped this: https://github.com/whatwg/html/commit/cef842d0ebb31f73695247daf0cf01ae71e99e3d

Search in github for "window.parent" OR frameElement in SVG files:

https://github.com/search?utf8=✓&l=svg&q="window.parent"+OR+"frameElement"&type=Code&ref=searchresults

First page of result has stuff like

<svg xmlns="http://www.w3.org/2000/svg" version="1.0" viewBox='0 0 56 51' onclick="if (window.frameElement &amp;&amp; window.frameElement.parentNode.nodeName === 'button') window.frameElement.parentNode.click()">

Another example:

https://github.com/Viruliant/Viruliant.GitHub.io/blob/bf5d6b55369edb20f922aca3a97e9f070c685bfa/venn.svg?short_path=f5b0f72 -- venn diagram that looks at <param> from parent.

This seems to be from https://www.w3.org/TR/SVGParamPrimer/ .

So at least it seems it would break things if SVG in <object> were changed to use an opaque origin.

I don't know how to find instances of SVG when used in top-level browsing context. Maybe a use counter could help? (It is possible to search httparchive based on use counter hits.)

So let's consider object/embed/iframe as direct authorization to access our origin, and put others into opaque one?

Dear Chromium Devs, esteemed Egor,

Are you considering to prevent SVG from loading eg .woff files, even if they're on the same domain? I am using fonts with SVG, and I hope you won't break that.

Example: https://codepen.io/TobiReif/full/ZpERON/

(In this example see "@font-face". There I ref an external domain, but generally I wouldn't have an issue with being required to host assets (eg fonts, CSS, and scripts) on the same domain as the SVG.)

Regarding "scripts are only there to make the image more "interactive"".

SVG is not just an image format. It's a first class web technology like HTML. It can load fonts and CSS and scripts and SVG fragments, for example. SVG can be used as part of serious web-apps. It is not just an image format.

Anyone who is eg hosting arbitrary user-supplied / potentially malicious SVG is required to know what SVG is. That's part of the job if the chosen job is to host user-supplied SVG.

If you're showing it with <embed>, it will keep working. Otherwise, you would need to add opt-in header to allow same origin. 

Our job is to sandbox some potentially dangerous uses of SVG and, if needed, let them add a header to turn the functionality back. Nobody is taking it back, just due to poor naming and history, we have to break tiny number of apps for greater good.

As someone who specializes in using SVG as an alternative markup language to HTML I would like to point out that the SVG abilities were put there for a purpose.

If you wish to treat SVG as just an image file and impose restrictions, be aware that you are impeding progress for those that wish to move beyond HTML as the basis for internet presentation.

The two ways of looking at web development language importance are quite different. Just because you are committed to one way of doing things should not condone hobbling others with a different viewpoint.

Established method of web design and an alternative method by language importance.

HTML            SVG
CSS             Javascript
Javascript      HTML
SVG             CSS

Please tread carefully with any changes to SVG, as you may not be seeing the forest through the trees. If your goal is to impede progress, Chromium is already doing a fine job by not fully supporting SVG. See bug:  534601 

Requiring all SVG developers (who didn't do anything wrong) to set a header stating that they trust their own content on their own domains - not good. Sure they trust their own content on their own domain. Their content should not be broken by browsers, and they shouldn't be required to set an additional header.

There seem to be a few who accept and publish potentially malicious SVG without ensuring any security precautions, because they were ignorant enough to not know what SVG is. There is not much hope that they're less ignorant now. AFAICS they could simply set the header, and continue to accept and publish arbitrary SVG without implementing any security measures. They didn't care about security in the first place, they could just as well continue to not care about security then. If they are to be educated, much more than a header-requirement will be necessary, including a broad education effort by all browser vendors targeting those specific websites (and future developers as well).