Bugzilla

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)
> Yeah, also I don't think we limit `<iframe>` for same-origin use cases? That's what `svg.use-element.graphics-element-restrictions` controls right now.

That pref seems to relate to same-vs-cross *document* use cases, not same-vs-cross *origin*.

But setting that aside: on the broader point, I agree with you: this shouldn't be considered XSS since these scripts only run when everything is same-origin. I tested with a cross-origin SVG file (two different http servers running on different ports) and got an error like this in my error console:
`Security Error: Content at http://localhost:8000/test-separatedoc-xor.html may not load data from http://localhost:8001/resource.svg.`
...and the `<use>`-clone failed entirely (nothing from it renders or fires event handlers), as expected.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)
> Yeah, also I don't think we limit `<iframe>` for same-origin use cases? That's what `svg.use-element.graphics-element-restrictions` controls right now.

That pref seems to relate to same-vs-cross *document* use cases, not same-vs-cross *origin*.  (In particular: we **do** limit `<iframe>` for same-origin-but-cross-document use-cases, depending on the value of that pref; see B vs. B' in my next comment.)

But setting that aside: on the broader point, I agree with you: this shouldn't be considered XSS since these scripts only run when everything is same-origin. I tested with a cross-origin SVG file (two different http servers running on different ports) and got an error like this in my error console:
`Security Error: Content at http://localhost:8000/test-separatedoc-xor.html may not load data from http://localhost:8001/resource.svg.`
...and the `<use>`-clone failed entirely (nothing from it renders or fires event handlers), as expected.