如何设置同源策略的端口部分？解决document.domain引发的跨域问题

Great question—this is a common gotcha with document.domain and same-origin policy (SOP) when dealing with iframes and differing ports. Let’s break down why this happens and walk through your viable solutions:

The Core Problem #

When you set document.domain in the parent page, browsers intentionally reset the port component to null as part of the SOP security model. Meanwhile, the iframe’s document retains its explicit port (80/443 by default, or whatever custom port it’s loaded from). Since null doesn’t match the iframe’s actual port, the SOP blocks the parent from accessing the iframe’s contentDocument.

Can the Parent JS Set the Port Part of the SOP? #

Short answer: No. Browsers don’t expose a way to manually set or override the port component of the origin for SOP checks via JavaScript. The document.domain API only lets you adjust the domain portion, and it always clears the port.

Your Workable Solutions #

Here are the most reliable ways to fix this access issue:

1. Sync document.domain in Both Parent and Iframe
   If you control the content of the iframe, have it set the same document.domain value as the parent. When both pages explicitly set document.domain to the same root domain (e.g., example.com), browsers ignore the port difference entirely for SOP checks.

   • Parent code:

     // Parent page (loaded from example.com:8080)
     document.domain = 'example.com';
     

   • Iframe code:

     // Iframe page (loaded from example.com:443)
     document.domain = 'example.com';
     

   After this, the parent can safely access iframe.contentDocument.

2. Use postMessage for Cross-Port Communication
   If you don’t control the iframe’s content (or can’t modify it), postMessage is the standard safe way to communicate across origins, including different ports. It lets you send structured data between the parent and iframe without bypassing SOP.

   • Parent code (send request and listen for response):

     const iframe = document.getElementById('my-iframe');
     // Send a request to the iframe (restrict origin to your domain in production!)
     iframe.contentWindow.postMessage('get-document-data', '*');
     
     // Listen for the response
     window.addEventListener('message', (event) => {
       // Verify the sender's origin for security
       if (event.origin !== 'https://example.com') return;
       console.log('Received data from iframe:', event.data);
     });
     

   • Iframe code (listen for request and send data back):

     window.addEventListener('message', (event) => {
       if (event.data === 'get-document-data') {
         // Send the desired document data back to the parent
         event.source.postMessage(document.documentElement.outerHTML, event.origin);
       }
     });
     

   Pro tip: Always replace * with the specific origin of the parent/iframe in production to prevent malicious message interception.

3. Unify Ports on the Server Side
   The simplest long-term fix is to host both the parent page and iframe content on the same port (either 80/443 for standard HTTP/HTTPS, or a custom shared port). This way, their origins are identical by default, and you won’t need to mess with document.domain at all.

Important Security Note #

Be cautious with document.domain: setting it to a broad root domain (e.g., .com) can expose your page to unintended cross-site interactions. Always set it to the most specific shared domain possible (e.g., example.com instead of .com).

内容的提问来源于stack exchange，提问作者Nithin Kumar Biliya