Can the source HTML/CSS/JS of a remote site shown in an <iframe> be accessed?

Question

It is obvious that much thought has gone into the design of Web infrastructure to provide good security for server-side Web programming. Yet no attention seems to be put on the issue of providing client-side security for material displayed by browsers, other than by the use of commercial security mechanisms for streaming commercial video content through our browsers.

I looked in the excellent MDN Web Docs (https://developer.mozilla.org/en-US/docs), but could not find any assurance that <iframe> provides or does not provide client-side security. Does it?

Napolitano

1) accessed by what? 2) developer.mozilla.org/en-US/docs/Web/Security/… – Estrin

Your quoted page states that JavaScript cannot read DOM data across different domains. Yet I can access an iframe on a remote site from my local computer. Isn't this different domains? The hostnames are different, at least. – Napolitano

you can, as the user operating the user agent and using its user-facing tools. scripts from different domains cannot "touch" each other. Your question is unclear with respect to that distinction. Or do you want me to write up an answer to that effect? the "domains" here are the domains of the different scripts- not of the script and user's machine. – Estrin

I would be grateful for such an answer. However, it is already clear from my experiments that iframes are pretty much useless without some other mechanism for client-side security. Until at least part of our browsers are implemented in Ring 0, we have not much chance of extending server-side security into client side. Same is true for other areas of client-side insecurity, such as email or the need to have authentication via email or telephone, or the elimination of all logins, and all spam and malware. None of that can be done without client-side security and/or effective enforcement of laws. – Napolitano

what do you mean by "client-side security"? You mean not letting the user view the source (HTML/CSS/JS/etc.) of the pages they're viewing? And not letting users use devtools? iframes being inspectable in devtools is not something specific to iframes. Whatever contains the iframes can also be inspected in devtools. I'm confused about why you're particular about iframes. Can you explain? – Estrin

Sure. One might think that iframes are a security mechanism. They completely encapsulate a separate document and window from the document and window pair in which they are declared. Since I could not find any information on the Web, I did some research and published my result as a question and answer. I suspect that there is NO way to encapsulate remote HTML, CSS, or JS such that it cannot be seen client-side. This is an important basic piece of knowledge that I wanted to find out myself. So long as security is important to an app, it must be at least partially implemented on the webserver. – Napolitano

Answer 1

If you're concerned about security, note that sites can respond to requests and specify that they should not be embedded by requesting user agents in iframes. See the X-Frame-Options HTTP header and frame-ancestors Content Security Policy.

If you're instead interested in protecting the embedder (rather than the embeddee), see the allow attribute of <iframe>s.

The main security mechanism you care about is the Same-Origin Policy, which basically is that resources from different origins should not have access to one another. If you want to read more about it, you may be interested in the MDN page and the Wikipedia page on the subject.

There are ways for resources from different origins to cooperate (basically both giving each other consent to communicate), such as window.postMessage. If the iframe page is from the same origin as the parent frame, then yes, the parent frame can "reach in" to the DOM of the child frame. Ex. Get element from within an iFrame.

A user operating a user agent (such as a browser) can still use tools provided by the user agent to inspect the resources of the sites, but that's not as much of a security concern- barring the user shooting themselves in the foot by very intentionally being a side-channel for information from one origin's resource to get to another's. Ex. copy and pasting things from browser devtools.

Estrin