SecurityError: bloqueó un marco con origen para acceder a un marco de origen cruzado

Estoy cargando un archivo <iframe>en mi página HTML e intento acceder a los elementos que contiene mediante Javascript, pero cuando intento ejecutar mi código, aparece el siguiente error:

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

¿Pueden ayudarme a encontrar una solución para poder acceder a los elementos en el marco?

Estoy usando este código para probar, pero en vano:

$(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!";
    });
});

Política del mismo origen

No puede acceder a un <iframe>origen diferente usando JavaScript, sería un gran defecto de seguridad si pudiera hacerlo. Para la política del mismo origen, los navegadores bloquean los scripts que intentan acceder a un marco con un origen diferente .

El origen se considera diferente si no se mantiene al menos una de las siguientes partes de la dirección:

<protocol>://<hostname>:<port>/...

El protocolo , el nombre de host y el puerto deben ser los mismos de su dominio, si desea acceder a un marco.

^{NOTA: se sabe que Internet Explorer no sigue estrictamente esta regla, consulte aquí para más detalles.}

Ejemplos

Esto es lo que sucedería al intentar acceder a las siguientes URL desde 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 

Solución alterna

Aunque la política del mismo origen bloquea el acceso de los scripts al contenido de sitios con un origen diferente, si posee ambas páginas, puede solucionar este problema utilizando window.postMessagey su messageevento relativo para enviar mensajes entre las dos páginas, de esta manera:

• En tu página principal:

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

  El segundo argumento postMessage()puede ser '*'indicar que no hay preferencia sobre el origen del destino. Siempre se debe proporcionar un origen de destino cuando sea posible, para evitar revelar los datos que envía a cualquier otro sitio.

• En su <iframe>(contenido en la página principal):

  window.addEventListener('message', event => {
      // IMPORTANT: check the origin of the data! 
      if (event.origin.startsWith('http://your-first-site.com')) { 
          // 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; 
      } 
  }); 
  

Este método se puede aplicar en ambas direcciones , creando un oyente en la página principal y recibiendo respuestas del marco. La misma lógica también se puede implementar en ventanas emergentes y, básicamente, en cualquier ventana nueva generada por la página principal (por ejemplo, usando window.open()), sin ninguna diferencia.

Deshabilitar la política del mismo origen en su navegador

Ya hay algunas buenas respuestas sobre este tema (las acabo de buscar en Google), por lo que, para los navegadores donde sea posible, vincularé la respuesta relativa. Sin embargo, recuerde que deshabilitar la política del mismo origen solo afectará a su navegador . Además, ejecutar un navegador con la configuración de seguridad del mismo origen deshabilitada otorga a cualquier sitio web acceso a recursos de origen cruzado, por lo que es muy inseguro y NUNCA debe hacerse si no sabe exactamente lo que está haciendo (por ejemplo, con fines de desarrollo) .

• Google Chrome
• Mozilla Firefox
• Safari
• Ópera
• Microsoft Edge: no es posible
• Microsoft Internet Explorer

Complementando la respuesta de Marco Bonelli: está utilizando la mejor forma actual de interactuar entre marcos / iframes window.postMessage, compatible con todos los navegadores

Verifique la http://www.<domain>.comconfiguración del servidor web del dominio. X-Frame-Options Es una característica de seguridad diseñada para evitar ataques de clickJacking,

¿Cómo funciona clickjacking?

1. La página del mal se ve exactamente como la página de la víctima.
2. Luego engañó a los usuarios para que ingresaran su nombre de usuario y contraseña.

Técnicamente el mal tiene una iframefuente con la página de la víctima.

<html>
    <iframe src='victim_domain.com'/>
    <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>

Cómo funciona la característica de seguridad

Si desea evitar que la solicitud del servidor web se procese dentro de un iframeagregar las opciones x-frame-

X-Frame-Options DENY

Las opciones son:

1. SAMEORIGIN // permitir solo que mi propio dominio represente mi HTML dentro de un iframe.
2. DENY // no permita que mi HTML se represente dentro de ningún iframe
3. "ALLOW-FROM https://example.com/ " // permitir que un dominio específico represente mi HTML dentro de un iframe

Este es el ejemplo de configuración de IIS:

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

La solución a la pregunta.

Si el servidor web activó la función de seguridad, puede causar un SecurityError del lado del cliente como debería.

Para mí, quería implementar un protocolo de enlace bidireccional, lo que significa:
- la ventana principal se cargará más rápido que el iframe
- el iframe debería hablar con la ventana principal tan pronto como esté listo
- el padre está listo para recibir el mensaje del iframe y reproducirlo

este código se usa para establecer la etiqueta blanca en el iframe usando el código [propiedad personalizada CSS]
:
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","*");
    }
});

padre

$(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);
});

naturalmente, puede limitar los orígenes y el texto, este es un código fácil de trabajar.
Este examen me pareció útil:
[Mensajes entre dominios con postMessage]

Me gustaría agregar la configuración específica de Java Spring que pueda afectar esto.

En el sitio web o la aplicación Gateway hay una configuración contentSecurityPolicy

en Spring puedes encontrar la implementación de la subclase WebSecurityConfigurerAdapter

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

...

.referrerPolicy(ReferrerPolicyHeaderWriter.ReferrerPolicy.STRICT_ORIGIN_WHEN_CROSS_ORIGIN)

El navegador se bloqueará si no ha definido un contenido externo seguro aquí.

Si tiene control sobre el contenido del iframe, es decir, si simplemente se carga en una configuración de origen cruzado como en Amazon Mechanical Turk, puede sortear este problema con el <body onload='my_func(my_arg)'>atributo para el html interno.

Por ejemplo, para el html interno, use el thisparámetro html (sí, thisestá definido y se refiere a la ventana principal del elemento del cuerpo interno):

<body onload='changeForm(this)'>

En el html interno:

    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>

• Abre el menú de inicio
• Escriba windows + R o abra "Ejecutar
• Ejecute el siguiente comando.

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