Why are file:// paths always treated as cross-domain?

Question

Why can't a local page like

file:///C:/index.html

Send a request for a resource

file:///C:/data.json

This is prevented because it's a cross origin request, but in what way is that cross origin? I don't understand why this is a vulnerability / prevented. It just seems like a massive pain when I want to whip up a quick utility for something in JavaScript/HTML and I can't run it without uploading to to a server somewhere because of this seemingly arbitrary restriction.

Hm, what browser is that? I dare say this is a pretty exotic thing, an issue only few people stumble upon. Reason simply is that few people use the file scheme in web development... — arkascha, Mar 07 '17 at 21:05
Not really an answer, but this may help: http://stackoverflow.com/questions/18586921/how-to-launch-html-using-chrome-at-allow-file-access-from-files-mode if you're using Chrome — Dan Field, Mar 07 '17 at 21:06
@arkascha Well, the place I've run into it multiple times is with "'CanvasRenderingContext2D': The canvas has been tainted by cross-origin data.", when trying to make some quick one-off image manipulation utility. I would certainly hope that the answer is not just that "It shouldn't be that way, but it's currently broken because nobody cares." — Mark, Mar 07 '17 at 21:08
@DanField I know that I can do that... and that's what I've done to fix it. But I want to know *why* I have to do that. And doing that is not a great option when I want to give a utility I've made in that way to someone else to use, as telling a non-technical user to go in and edit their shortcut with extra flags is awkward. — Mark, Mar 07 '17 at 21:10

score 3 · Accepted Answer · answered Mar 07 '17 at 21:14

HTML files are expected to be "safe". Tricking people into saving an HTML document to their hard drive and then opening it is not difficult (Here, just open the HTML file attached to this email would cause many email clients to automatically safe it to a tmp directory and open it in the default application).

If JavaScript in that file had permission to read any file on the disk, then users would be extremely vulnerable.

It's the same reason that software like Microsoft Word prompts before allowing macros to run.

score 2 · Answer 2 · answered Mar 07 '17 at 21:10

2

It protects you from malicious HTML files reading from your hard drive.

On a real server, you are (hopefully) not serving arbitrary files, but on your local machine, you could very easily trick users into loading whatever you want.

answered Mar 07 '17 at 21:10

mcrumley

5,552
3
23
31

But how is it any more of a vulnerability than a malicious executable file on your machine doing the same thing? If the malicious files are on your local file system you've already been pretty much successfully attacked at that point haven't you? – Mark Mar 07 '17 at 21:14
It's not any more dangerous than an executable file, but it's easier to trick people into downloading one, and it's harder for your anti virus to detect. – mcrumley Mar 07 '17 at 21:18

score 1 · Answer 3 · edited May 23 '17 at 12:31

Browsers are set up with security measures to make sure that ordinary users won't be at increased risk. Imagine that I'm a malicious website and I have you download something to your filesystem that looks, to you, like a regular website. Imagine that downloaded HTML can access other parts of your file system and then send that data to me through AJAX or perhaps another piece of executable code on the filesystem that came with this package. To a regular user this might look like a regular website that just "opened up a little weird but I still got it to work." If the browser prevents that, they're safer.

It's possible to turn these flags off (as in here: How to launch html using Chrome at "--allow-file-access-from-files" mode?), but that's more for knowledgeable users ("power users"), and probably comes with some kind of warning about how your browsing session isn't secure.

For the kind of scenarios you're talking about, you should be able to spin up a local HTTP server of some sort - perhaps using Python, Ruby, or node.js (I imagine node.js would be an attractive option for testing javascript base apps).

Why are file:// paths always treated as cross-domain?

3 Answers3