Develop Reference

Same-Origin Policy: Understanding Deny Read

This MSDN article explains that READS are not permitted by the same-origin policy.
Specifically, it says:
Webpage from Origin A:
May include (execute) a frame pointed at a HTML page from “B”
Must not be permitted to get the inner HTML of that frame
How can another html file be "included (executed)", without the content of it being accessed?
What does "included (executed)" even mean in this context?

This is referring to the fact that the user viewing the page can see the content of the iframe, but scripts running on the framing page cannot access the content of the framed page. Consider analogously that an <img> tag will show an image from any origin to a user, but scripts within the page that contains the <img> tag might not be able to read the contents of the loaded image.
This is important because the framed page is from a different origin and was fetched using the user's cookies from that origin. Suppose the framed page was mail.google.com: certainly I don't want any random webpage to read the contents of my inbox simply by loading it in an iframe. However, merely showing the page to me, the user who happens to be logged in to my mail service, is harmless.

Determining the iframe parent

I have a web page that will be embedded in iframes on multiple domains. I need to determine which domain is embedding my content.
document.referrer doesn't work, because I need the parent window, not the home page of the site or the page last visited prior to navigating to my page.
I don't have any control over the sites that are embedding my content.

Because of abuse over the years Web-browsers & servers have added security.
One of them being is preventing an iframe from accessing the parent Domain unless it meets the SAME ORIGIN POLICY.
https://en.wikipedia.org/wiki/Same-origin_policy
Now the HOST which your website will be embedded can allow access your to access the parent host. Something called CORS for short.
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
Also check out.
https://en.wikipedia.org/wiki/Web_Messaging
Hope that answer your question some.

Recommended method to prevent any content inside iframe from setting cookies

I get the content to be put inside an iframe from a source I do not trust. For a particular need to be met, I want the content (which might include javascript) to be unable to set cookies at all. What is the recommended method to achieve that?
Edit: I recognize this is similar to this question. I should have mentioned this earlier, but the iframe has a cross-origin source. I want to disable the content inside from setting cookies even on its own source. Does sandboxing achieve that? Thanks.

The short answer:
The HTML5 sandbox attribute prevents an iframe from reading/writing cookies. This is true for both same-origin and cross-origin iframes.
The allow-scripts attribute enables JavaScript but does not interfere with restrictions on cookies.
<iframe sandbox="allow-scripts" src="..."></iframe>
The long answer:
So if you're not fully convinced, this one is for you...
According to the W3C Working Draft (2010) and W3C Recommendation (2014), when the user agent (browser) parses the sandbox attribute, it has to add certain flags, which are then used to put restrictions on the content within the iframe. One of those flags are meant to force the content into a unique origin, and prevent it from reading/writing cookies:
The sandbox attribute, when specified, enables a set of extra restrictions on any content hosted by the iframe.
While the sandbox attribute is specified, the iframe element's nested browsing context must have the flags given in the following list set.
...
...
The sandboxed origin browsing context flag, unless the sandbox attribute's value, when split on spaces, is found to have the allow-same-origin keyword set
This flag forces content into a unique origin, thus preventing it from accessing other content from the same origin.
This flag also prevents script from reading from or writing to the document.cookie IDL attribute, and blocks access to localStorage. [WEBSTORAGE]
When a sandboxed iframe attempts to write a cookie, the following exception is raised:
Uncaught DOMException: Failed to set the 'cookie' property on 'Document': The document is sandboxed and lacks the 'allow-same-origin' flag.
and no cookie is ever written.
Since the sandboxed iframe cannot write cookies at all, it will not be able to set cookies even on its originating site.
(In fact, this would be one of the use-cases for using the allow-same-origin keyword).
The allow-same-origin attribute is intended for two cases.
...
Second, it can be used to embed content from a third-party site, sandboxed to prevent that site from opening popup windows, etc, without preventing the embedded page from communicating back to its originating site, using the database APIs to store data, etc.

Why can an iframe change the parent window's URL from a different domain?

I have two domains:
sub1.domain.org contains an iframe with its src pointing to the other: sub2.domain.org
On sub2:
//triggers a cross-domain security error
alert(window.parent.location.href);
//executes just fine on FF, IE, Chrome, and Safari.
window.parent.location.href = new_url;
So it appears I'm allowed to write to the parent window's URL, but I'm not allowed to read it. Is that really the standard? I just need to know why this is working as it does.
I found one answer here: Why can a child redirect a parent frame?
the Same origin policy doesn't apply here, either. By changing the url
in the address bar in your browser window, you're changing the
window.top.location.href property, too. If there were same-origin
restrictions there, the internet would be dead. You're not sending a
request to another location, you're not getting data from a
third-party resource and loading it in your page, you're redirecting
the browser to another location, which closes and clears the DOM.
But this answer prompts other follow up questions.
When we change the parent's URL, aren't we still technically modifying the parent's DOM (even if it closes it) and therefore violating the same-origin policy?
How exactly would the internet be dead if the same origin policy applied here? Surely we can differentiate manually entering URLs in the address bar from changing it via scripts on separate domains.
I understand that this case is not violating the same-origin policy, but I'm still struggling to understand exactly why. Can anyone shed additional insight as to why this is allowed?

It is not a security problem for an iframe to change the URL of a parent window. That just loads a new page into the parent window (thus killing the iframe that was contained in the original parent). There's no security issue there.
The iframe from a different origin is (as you have noticed) not allowed to access the content of a parent as that could be a security issue.
FYI, the reverse is also true. A parent frame can create an iframe and set it's .src to whatever it wants, including other domains, but cannot access the content that loads. The core issue here is that it is not a security problem to display content from other domains, but it can be a security issue to access the actual content from a different origin. So, you're generally allowed to display whatever you want, just not access it.
FYI, the ability to detect whether you are being framed and "bust" out of the frame by resetting the parent window source URL is known as "frame busting" and it is considered a content provider's right to decide whether or not they can be framed or not or who they can be framed by. There are now newer controls that specify whether a site can be framed or not so frame busting is not required in newer browsers.

Get innerHTML of iframe loaded in chrome background page

I'm loading a webpage inside iframe of a background page in chrome extension. I need to fetch the content (i.e. DOM) of iframe. I'm getting protocol error. how to overcome this situation, any workaround.
"Unsafe JavaScript attempt to access frame with URL https://swym.3ds.com/ from frame with URL chrome-extension://ohhaffjbbhlfbbpcdcajbkeippadmipk/back.html. The frame requesting access has a protocol of 'chrome-extension', the frame being accessed has a protocol of 'https'. Protocols must match."
I'm trying to implement a desktop notification for the above site, hiding the process from user eye.
I tried using XMLHTTPRequest and Jquery GET, unfortunately my site loading is unstandard, it doesn't work as intended.
Any suggestion on this topic will be very helpful.

It seems you're facing Cross-origin resource sharing issues. Do a quick check for resources loaded with protocols, convert http://www.example.com resources to //www.example.com Also refer MDN CORS Article

Javascript cannot access content on another domain as it poses security risks. If you have control over the domains, you may use postMessage to overcome this. Take a look at this link