In some cases, the same-origin policy can be too strict. Here are three less-strict same-origin policies

domain

The same origin policy causes problems for large sites that use multiple subdomains. For example, a script in a document from home.example.com wants to legally read the properties of a document loaded from developer.example.com, Or a script from orders.example.com might need to read the properties of the document on catalog.example.com. To support this type of multi-domain site, you can use the domain property of the Document object. By default, the domain property holds the host name of the server on which the document is loaded. You can set this property, but the string used must have a valid field prefix or itself. So if the initial value of a domain attribute is the string “home.exaple.com”, you can set it to the string “example.com”, but not to “home.example”. In addition. There must be a dot in the domain value. It cannot be set to com or any other top-level domain.

If two Windows (or forms) contain scripts that set the domain to the same value, they are no longer subject to the same origin policy and can read each other’s properties. For example, scripts in documents loaded from order.example.com and catalog.example.com could set their document.domain property to “example.com” so that the documents have homology and can read properties from each other.

Cross-domain resource sharing CORS

Cross-domain Resource Sharing (Cross – Origin the Resource Sharing, see http://www.w3.org/TR/cors). The draft standard extends HTTP with a new “Origin:” request header and a new Access-Control-Allow-Origin response header. It allows the server to explicitly list sources with header information, or to match all sources with wildcards and to request files from any address. Browsers like Firefox and Safari can use this new header to allow traversal of HTTP requests so that XMLHttpRequest is not restricted by the same origin policy.

Cross-document message postMessage()

Cross-document Messaging allows scripts from one document to pass text messages to scripts in another document, regardless of the source of the script. Calling the postMessage() method on the Window object asynchronously passes message events (which can be handled by the onMessage event handler function) to the Window’s document. Scripts in one document still cannot call methods and read properties in other documents. But they can use this messaging technology for secure communication.