SecurityError: Blocked a frame with origin from accessing a cross-origin frame
Asked Answered
K

9

842

I am loading an <iframe> in my HTML page and trying to access the elements within it using JavaScript, but when I try to execute my code, I get the following error:

SecurityError: Blocked a frame with origin "http://www.example.com" from accessing a cross-origin frame.

How can I access the elements in the frame?

I am using this code for testing, but in vain:

$(document).ready(function() {
    var iframeWindow = document.getElementById("my-iframe-id").contentWindow;

    iframeWindow.addEventListener("load", function() {
        var doc = iframe.contentDocument || iframe.contentWindow.document;
        var target = doc.getElementById("my-target-id");

        target.innerHTML = "Found it!";
    });
});
Keare answered 2/8, 2014 at 18:14 Comment(2)
window.postMessage() developer.mozilla.org/en-US/docs/Web/API/Window/postMessageAngelenaangeleno
I actually used window.postMessage() and still get the error the OP mentioned when trying to access event.source in the target window.Culpepper
C
1174

Same-origin policy

You can't access an <iframe> with different origin using JavaScript, it would be a huge security flaw if you could do it. For the same-origin policy browsers block scripts trying to access a frame with a different origin.

Origin is considered different if at least one of the following parts of the address isn't maintained:

protocol://hostname:port/...

Protocol, hostname and port must be the same of your domain if you want to access a frame.

NOTE: though mostly unused nowadays, Internet Explorer is known to not strictly follow this rule, see here for details.

Examples

Here's what would happen trying to access the following URLs from http://www.example.com/home/index.html

URL                                             RESULT
http://www.example.com/home/other.html       -> Success
http://www.example.com/dir/inner/another.php -> Success
http://www.example.com:80                    -> Success (default port for HTTP)
http://www.example.com:2251                  -> Failure: different port
http://data.example.com/dir/other.html       -> Failure: different hostname
https://www.example.com/home/index.html:80   -> Failure: different protocol
ftp://www.example.com:21                     -> Failure: different protocol & port
https://google.com/search?q=james+bond       -> Failure: different protocol, port & hostname

Workaround

Even though same-origin policy blocks scripts from accessing the content of sites with a different origin, if you own both the pages, you can work around this problem using window.postMessage and its relative message event to send messages between the two pages, like this:

  • In your main page:

    const frame = document.getElementById('your-frame-id');
    frame.contentWindow.postMessage(/*any variable or object here*/, 'https://your-second-site.example');
    

    The second argument to postMessage() can be '*' to indicate no preference about the origin of the destination. A target origin should always be provided when possible, to avoid disclosing the data you send to any other site.

  • In your <iframe> (contained in the main page):

    window.addEventListener('message', event => {
        // IMPORTANT: check the origin of the data!
        if (event.origin === 'https://your-first-site.example') {
            // The data was sent from your site.
            // Data sent with postMessage is stored in event.data:
            console.log(event.data);
        } else {
            // The data was NOT sent from your site!
            // Be careful! Do not use it. This else branch is
            // here just for clarity, you usually shouldn't need it.
            return;
        }
    });
    

This method can be applied in both directions, creating a listener in the main page too, and receiving responses from the frame. The same logic can also be implemented in pop-ups and basically any new window generated by the main page (e.g. using window.open()) as well, without any difference.

Disabling same-origin policy in your browser

There already are some good answers about this topic (I just found them googling), so, for the browsers where this is possible, I'll link the relative answer. However, please remember that disabling the same-origin policy will only affect your browser. Also, running a browser with same-origin security settings disabled grants any website access to cross-origin resources, so it's very unsafe and should NEVER be done if you do not know exactly what you are doing (e.g. development purposes).

Conspire answered 2/8, 2014 at 18:28 Comment(30)
Any other answer I've found 1, 2, suggests that CORS/Access-Control-Allow-Origin does not apply to iFrames, only to XHRs, Fonts, WebGL and canvas.drawImage. I believe postMessage is the only option.Bowens
what if the origin is: yousite.com.mysite.com ? should we use === instead?Chamness
How to avoid the exception by skipping the access that causes it in the first place? to be more specific I have a code that runs against the window object of a given page to inspect elements and on some pages the script is interrupted due to this error. I have no intention of accessing any references to other windows/iframes and want to safely ignore them in my code but haven't found a way to do so! any suggestions?Kimberelykimberlee
@SabaAhang just check for the iframe.src, and if the site it's different from your domain's hostname then you can't access that frame.Conspire
@MarcoBonelli, When using window.postMessage Workaround, what are the domain protocol restrictions? For Instance, is it possible to post message from an https origin to an http target iframe and vice-versa?Ria
@Ria of course, as long as you own both domains you can set a sender on the main one and a receiver on the dimain in the frame. By the way the browser may warn you or (worst case) block the frame from loading if it'a http loading in an https page, you may want to check on that first.Conspire
For simple cases another workaround would be to pass GET parameters as part of the src and extract them on the recieving side through location object, ex <iframe src='foobar.com/?sCSS=color%3Ared'></iframe>Mayle
After almost cry, I check @parliament suggestion and the porthole library works excellent. If anyone is struggling with this issue I will recommend to use it. The other ways are quite messy to implement and prone to errors. I implemented with Asp.Net Mvc with out problems.Debbi
@Redzarf: I think we can avoid not and != 1. We can put the body in else part to if part and put body of if into else part.Bedroll
#29984286 check it outPostexilian
Here is the exact list of data types that can be passed as the message parameter into postMessage(), although "any variable or object" is a reasonable summary. Also, if(document.referrer.indexOf(event.origin) == 0) is a dynamic way to check whether a message to an iframe came from its parent window.Propertius
Actually, document.referrer.indexOf(event.origin) == 0 is not a dynamic way to check whether a message to an <iframe> came from its parent window. document.referrer is not the URL of your parent window, also if the event.origin doesn't exactly match you will get false negatives: if you have a page which changes its location using for example the history API, this will basically always fail. Don't do this, it's bad.Conspire
@MarcoBonelli Hi, I am using <embed> instead of <iframe>, it doesn't wok for me. var embed = document.getElementById('your-embed-id'); embed.contentWindow.postMessage(/*any variable or object here*/, '*'); I got Uncaught TypeError: Cannot read property 'postMessage' of undefinedImproper
@Improper <embed> has nothing to do with frames.Conspire
How do you explain this: gyazo.com/caf4dda723bc0afd0baa058172d91573Ubangi
@MarcoBonelli it's blocking a frame from the same origin. Here is what you said: example.com/home/other.html -> Success example.com/dir/inner/another.php -> SuccessUbangi
@ZeusZdravkov Sorry I misread the URLs, okay they seem to have the same origin, but the origin is not the same thing that can block a frame from being loaded. There's not much to say without seeing more of the server and client side of that page. You should post a more detailed question.Conspire
Instead of "h t t p ://yoursite.com", you may be able to use location.ancestorOrigins[0] instead to avoid hardcode.Idocrase
@Idocrase that's a terrible idea. If you check for event.origin.indexOf(location.ancestorOrigins[0]) you are basically allowing any parent frame to access your frame, and as you can imagine, that's a very bad idea.Conspire
@Marco Bonelli Please explain "any" and "bad". I have one parent frame that needs to be accessed. There are no more than 1. the iFrame posts a message to this one parent. This is good. And by the way, I actually changed location.ancestorOrigins[0] which worked with Chrome to document.referrer which works for all browsers.Idocrase
@Idocrase location.ancestorOrigins[0] is the location of the parent frame. If your frame is running inside another site and you check using event.origin.indexOf(location.ancestorOrigins[0]) you are checking if the origin of the event contains the parent's frame address, which is always going to be true, therefore you are allowing any parent with any origin to access your frame, and this is obviously not something you want to do. Moreover, document.referrer is bad practice too, as I already explained in the comments above.Conspire
I'm surprised this entire page doesn't mention document.domain.Elouise
@JimW that's because it's only the hostname, it doesn't cover the protocol.You wouldn't want, for example, to allow messages from an http:// page if your frame is under https:// (and possibly even vice-versa).Conspire
If you are using an object instead of an iframe and want to access the postMessage function of it in the Internet Explorer you must go this way document.getElementById('youtObjectId').contentDocument.defaultView.postMessage(message, origin);. This will not work in the Chrome browserHeterocyclic
Can I apply the same principle when developing a chrome extension as isolated iframe? As far as I understand I could write the first code snippet inside my 'content.js' script and second code snippet inside the 'app.js' from my 'iframe'. Is that right?Rosales
If you got Property 'contentWindow' does not exist on type 'HTMLElement' just follow the answer hereCohin
you really want to call yourWIndow.opener.postMessage(...) when sending from your popup to your main window else it wont sendParticipate
That origin check is insecure: 'http://your-first-site.example.attacker.com'.startsWith('http://your-first-site.example') would be true.Whalebone
@Whalebone thanks for pointing that out. Unbelievable that such a piece of code has been sitting there for such a long time. Updated!Conspire
It seems that disabling CORS with --disable-web-security doesn't work for iframes.Bakery
B
69

Complementing Marco Bonelli's answer: the best current way of interacting between frames/iframes is using window.postMessage, supported by all browsers

Badenpowell answered 9/10, 2014 at 14:0 Comment(3)
window.postMessage we can use only if we can able to access both parent(our HTML page) and children element(other domain iframe).Otherwise "THERE IS NO POSSIBILITY", it will always throws an error "Uncaught DOMException: Blocked a frame with origin "<yourdomainname.com>" from accessing a cross-origin frame."Yves
Except this doesn't seem to work correctly for local files. If I do window.opener.postMessage( { }, "*" ); in a popup window, then the parent window will not be able to access event.source. I get "Blocked a frame with origin "null" from accessing a cross-origin frame." This is ironic, since the documentation specifically states that the entire point of postMessage is to allow secure communication across different origins.Culpepper
I can neither get around the 'Blocked a frame with origin' browser error. Did you find a way @LeslieKrause? I need to display a cross origin iframe, but not succeeding with postMessage.Wholewheat
H
29

Check the domain's web server for http://www.example.com configuration for X-Frame-Options It is a security feature designed to prevent clickJacking attacks,

How Does clickJacking work?

  1. The evil page looks exactly like the victim page.
  2. Then it tricked users to enter their username and password.

Technically the evil has an iframe with the source to the victim page.

<html>
    <iframe src='victim-domain.example'/>
    <input id="username" type="text" style="display: none;"/>
    <input id="password" type="text" style="display: none;"/>
    <script>
        //some JS code that click jacking the user username and input from inside the iframe...
    <script/>
<html>

How the security feature work

If you want to prevent web server request to be rendered within an iframe add the x-frame-options

X-Frame-Options DENY

The options are:

  1. SAMEORIGIN: allow only to my own domain render my HTML inside an iframe.
  2. DENY: do not allow my HTML to be rendered inside any iframe
  3. ALLOW-FROM https://example.com/: allow specific domain to render my HTML inside an iframe

This is IIS config example:

   <httpProtocol>
       <customHeaders>
           <add name="X-Frame-Options" value="SAMEORIGIN" />
       </customHeaders>
   </httpProtocol>

The solution to the question

If the web server activated the security feature it may cause a client-side SecurityError as it should.

Homochromatic answered 6/9, 2017 at 10:24 Comment(2)
I don't think that X-Frame-Options applies here - X-Frame-Options defined by the guest (embedded) page can cause the parent to refuse to load the page, but as far as I know it doesn't affect javascript access - even with X-Frame-Options: *, I don't think you'll be able to access the DOM of a different origin guest page with javascriptDalmatic
This answer didn't actually answered the question, the question didn't ask if this was safe or not.Present
G
20

For me i wanted to implement a 2-way handshake, meaning:
- the parent window will load faster then the iframe
- the iframe should talk to the parent window as soon as its ready
- the parent is ready to receive the iframe message and replay

this code is used to set white label in the iframe using [CSS custom property]
code:
iframe

$(function() {
    window.onload = function() {
        // create listener
        function receiveMessage(e) {
            document.documentElement.style.setProperty('--header_bg', e.data.wl.header_bg);
            document.documentElement.style.setProperty('--header_text', e.data.wl.header_text);
            document.documentElement.style.setProperty('--button_bg', e.data.wl.button_bg);
            //alert(e.data.data.header_bg);
        }
        window.addEventListener('message', receiveMessage);
        // call parent
        parent.postMessage("GetWhiteLabel","*");
    }
});

parent

$(function() {
    // create listener
    var eventMethod = window.addEventListener ? "addEventListener" : "attachEvent";
    var eventer = window[eventMethod];
    var messageEvent = eventMethod == "attachEvent" ? "onmessage" : "message";
    eventer(messageEvent, function (e) {
        // replay to child (iframe) 
        document.getElementById('wrapper-iframe').contentWindow.postMessage(
            {
                event_id: 'white_label_message',
                wl: {
                    header_bg: $('#Header').css('background-color'),
                    header_text: $('#Header .HoverMenu a').css('color'),
                    button_bg: $('#Header .HoverMenu a').css('background-color')
                }
            },
            '*'
        );
    }, false);
});

naturally you can limit the origins and the text, this is easy-to-work-with code
i found this examlpe to be helpful:
[Cross-Domain Messaging With postMessage]

Guano answered 13/12, 2017 at 17:32 Comment(2)
i'm dealing with an issue with safari where document in iframe is executing its JS later than parent page which causes the message to be sent earlier than document in iframe is listening to messages; which is exactly opposite from what chrome and firefox do - have you tested your code in safari on ios? btw postMessage with second parameter of value "*" is not quite safe, you should always specify domainPair
Your first block of code, is that on the iframe in the parent or is it on the page that gets loaded into the iframe ?Albertinealbertite
E
3

There is a workaround, actually, for specific scenarios.

If you have two processes running on the same domain but different ports, the two Windows can interact without limitations. (i.e. localhost:3000 & localhost:2000). To make this work, each window needs to change their domain to the shared origin:

document.domain = 'localhost'

This also works in the scenario that you are working with different subdomains on the same second-level domain, i.e. you are on john.site.example trying to access peter.site.example or just site.example

document.domain = 'site.example'

By explicitily setting document.domain; the browser will ignore the hostname difference and the Windows can be treated as coming from the 'same-origin'. Now, in a parent window, you can reach into the iframe: frame.contentWindow.document.body.classList.add('happyDev')

Eliga answered 20/11, 2021 at 0:1 Comment(1)
Chrome will disable modifying document.domain from version 106. See developer.chrome.com/blog/immutable-document-domainFirman
E
0

I would like to add Java Spring specific configuration that can effect on this.

In Web site or Gateway application there is a contentSecurityPolicy setting

in Spring you can find implementation of WebSecurityConfigurerAdapter sub class

contentSecurityPolicy("
script-src 'self' [URLDomain]/scripts ; 
style-src 'self' [URLDomain]/styles;
frame-src 'self' [URLDomain]/frameUrl...

...

.referrerPolicy(ReferrerPolicyHeaderWriter.ReferrerPolicy.STRICT_ORIGIN_WHEN_CROSS_ORIGIN)

Browser will be blocked if you have not define safe external contenet here.

Eleph answered 28/3, 2020 at 2:11 Comment(0)
B
0

If you have control over the content of the iframe - that is, if it is merely loaded in a cross-origin setup such as on Amazon Mechanical Turk - you can circumvent this problem with the <body onload='my_func(my_arg)'> attribute for the inner html.

For example, for the inner html, use the this html parameter (yes - this is defined and it refers to the parent window of the inner body element):

<body onload='changeForm(this)'>

In the inner html :

    function changeForm(window) {
        console.log('inner window loaded: do whatever you want with the inner html');
        window.document.getElementById('mturk_form').style.display = 'none';
    </script>
Broz answered 21/5, 2020 at 21:41 Comment(0)
H
0

I experienced this error when trying to embed an iframe and then opening the site with Brave. The error went away when I changed to "Shields Down" for the site in question. Obviously, this is not a full solution, since anyone else visiting the site with Brave will run into the same issue. To actually resolve it I would need to do one of the other things listed on this page. But at least I now know where the problem lies.

Hawsepiece answered 26/6, 2020 at 13:46 Comment(0)
E
-72
  • Open the start menu
  • Type windows+R or open "Run
  • Execute the following command.

chrome.exe --user-data-dir="C://Chrome dev session" --disable-web-security

Empress answered 22/9, 2018 at 6:25 Comment(2)
Terrible for anything that is not a quick and dirty test … and already address in the accepted answer.Bluestone
Even with the command, it doesn´t work because Chrome avoids disabling the web security this wayCacciatore

© 2022 - 2024 — McMap. All rights reserved.