This mechanism bears a particular significance for modern web applications that extensively depend on HTTPS cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions.
A strict separation between content provided by unrelated sites must be maintained on the client-side to prevent the loss of data confidentiality or integrity.
This means that resources such as images, CSS, and dynamically loaded scripts can be accessed across origins via the corresponding HTML tags (with fonts being a notable exception).
Unlike other browsers, Internet Explorer does not include the port in the calculation of the origin, using the Security Zone in its place.
At first, a number of workarounds such as using the fragment identifier or the window.name property were used to pass data between documents residing in different domains.
Modern browsers support multiple techniques for relaxing the same-origin policy in a controlled manner: Netscape Navigator briefly contained a taint checking feature.
[9] The feature was turned off by default, but if enabled by a user it would allow websites to attempt to read JavaScript properties of windows and frames belonging to a different domain.
[9] The other technique for relaxing the same-origin policy is standardized under the name Cross-Origin Resource Sharing (CORS).
Browsers such as Firefox 3.5, Safari 4 and Internet Explorer 10 use this header to allow the cross-origin HTTP requests with XMLHttpRequest that would otherwise have been forbidden by the same-origin policy.
When the script resource is loaded by the browser, the designated callback function will be invoked to process the wrapped JSON payload.
To ensure cross-site security, the WebSocket server must compare the header data against an allowlist of origins permitted to receive a reply.
The behavior of same-origin checks and related mechanisms is not well-defined in a number of corner cases such as for pseudo-protocols that do not have a clearly defined host name or port associated with their URLs (file:, data:, etc.).
Lastly, certain types of attacks, such as DNS rebinding or server-side proxies, permit the host name check to be partly subverted, and make it possible for rogue web pages to directly interact with sites through addresses other than their "true", canonical origin.
Therefore, if an endpoint uses a one of these "safe" request methods to write information or perform an action on a user's behalf, it can be exploited by attackers.