The same-origin policy

Sooner or later, web developers run up against the same-origin policy. Maybe you want to trigger a script on one domain and use the results on a different domain, but you can't.

The same-origin policy is necessary for web application security. The execution of a script may expose sensitive information. Access to this information is limited to the same domain where the script is located, unless access for an external domain has been specifically allowed by code.

Note

The same-origin policy is defined by the Internet Engineering Task Force (IETF) (https://tools.ietf.org/html/rfc6454#page-4).

A major motivation for implementing the same-origin policy is to protect sensitive information stored in cookies from being exposed to another domain. Web applications maintain authenticated user sessions in cookies. The user's personalizations and account information are stored in cookies. To ensure data confidentiality, cookies may not be shared across domains. For cookies, the same origin is shared by the domain or a sub-domain of that domain. For DOM elements such as scripts, the restrictions are more fine-grained.

The same-origin policy also applies to requests made with XMLHttpRequest (XHR). We will see how the Access-Control-Allow-Origin header facilitates the bending of the same-origin policy.

Notably, JSON-P, WebSocket, and window.postMessage are not restricted by the same-origin policy.