Reputation: 417
I have a page + javascript which reads a users SVG file into a HTML < object >'s data, and then modifies the SVG's DOM using javascript.
EDIT: The user selects a file from their own file system using an input field of type file.
This all works well within firefox, but both edge and chrome balk citing the single-origin policy (as I understand it, chrome spits out
Blocked a frame with origin "null" from accessing a cross-origin frame.
while edge just refuses to read the objects data).
If I understand the single-origin policy well enough, and the risks involved, edge and chrome's refusal to play with the loaded SVG is legitimate. Firstly, am I mistaken?
Secondly, how do I get past this problem? Is there a way? Would having the user upload the SVG to the server and then have it loaded in (so that it shares the origin as my page) work - and if so, is this safe?
I am looking for the "proper" way to do this: safe for my site, safe for the user, etc.
Thanks
Similar questions:
Apologies if I should have done something with these questions rather than ask again. I was hoping that with more current techniques a solution might be found.
Upvotes: 4
Views: 213
Reputation: 3247
Use <svg>
directly inside the HTML an put the file in there.
Because user upload their own file, there should be no risk.
You should still verify if the svg file is indeed a valid svg file without onload, <script>
etc inside. It is possible to validate svg without executing it. Use a white-list strategy and do this before using innerHTML
. (Because users could have received a malicious svg file per message from an attacker for instance). Never trust user input.
Upvotes: 1