3

Yes, the browser and webserver are on the same machine!

Whenever I try to embed a HTML file from outside of the WWW root in an iframe, thus using the file:/// URL syntax, it is ignored. No error message logged or anything. Just nothing is done whatsoever.

If I change the path from file:///C:\blablabla.html to ./blablabla.html, and put the file in the WWW root, it will display the HTML page in the iframe. So it's not some kind of fundamental issue with displaying iframes or anything. I have tried both with and without URL-encoding the C:\... part.

Are IFRAMEs inherently unable to display file:/// URIs, even though the MozDev page mentions no restrictions whatsoever for the src attribute? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe

2

I've just whipped up a very quick test and confirm I have no problem displaying file:/// URL's in an iframe in either Chrome or Firefox.

I do note that I use Linux on my desktop. I suspect (but can't easily test) that, as per 1.2.3 of RFC3986 the issue is your use of a backslash character - the spec requires the delimeter be "/" although I would expect whether backslashes work might be browser implementation specific.

2
  • Well, I just tried now with all the \s turned into /s but the same thing happens: no iframe contents and no errors or network tab events logged. Pale Moon on Windows.
    – Goedken
    Nov 25 '20 at 3:03
  • 2
    Have a read of kb.mozillazine.org/… - another limitation - and one you would be running into is that most browsers will prevent you from including a local file from a remote website, which means you cant mix http:// or https:// URLs with file:/// iframes at least for Firefox based browsers, and probably all browsers. As Pale Moon is a fork of Firefox that would explain it.
    – davidgo
    Nov 25 '20 at 3:31
2

file: URLs are problematic from a security standpoint. Modern browsers have added many restrictions on file: URLs. It isn't just in iframes. file: URLs are blocked as the source for

  • images
  • JavaScript
  • CSS
  • XHR (AJAX) calls
  • iframes
  • framesets

The basic vulnerability is that an attacker could grab a sensitive file from the local file system when you visit their web site. Consider the following which without restrictions on the iframe would load login information for many systems:

<iframe src=file:///etc/passwd>

Iframes are typically sand boxed such that the parent site doesn't have complete access to them. However, sand boxing isn't foolproof and hackers have found certain cases that allow them to get around it.

Another vulnerability is forcing the user of a website to download a malicious file (usually HTML, PDF, or DOC) and then using an iframe with a file: URL to execute that file from the local downloads directory. In older browsers when that happens, the malicious file runs with full access to the local file system.

To combat these problems modern browsers have:

  • Restricted live sites from using embedding file: URLs as described above
  • Restricted live sites frome even linking to file: URLs. Now when you click on a link to a file: URL, nothing happens and an error message appears in the developer console.
  • Restricted locally opened file: URLs from accessing the entire local system. In some modern browsers, local file: URLs can't even run JavaScript or load images, even when those resources are in the same directory.

If you are trying to develop a website locally most browsers allow you to turn off some of these restrictions so that you can get your work done. Just don't use your browser on live sites with these security restrictions turned off. For example in there are instructions for doing so in Firefox.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.