There is no single same-origin policy.
An origin is defined by the scheme, host, and port of a URL. Generally speaking, documents retrieved from distinct origins are isolated from each other. For example, if a document retrieved from http://example.com/doc.html tries to access the DOM of a document retrieved from https://example.com/target.html, the user agent will disallow access because the origin of the first document, (http, example.com, 80), does not match the origin of the second document (https, example.com, 443).
Although the same-origin policy differs between APIs, the overarching intent is to let users visit untrusted web sites without those web sites interfering with the user's session with honest web sites.
For networking APIs, the same-origin policy distinguishes between sending and receiving information. Broadly, one origin is permitted to send information to another origin, but one origin is not permitted to receive information from another origin. The prohibition on receiving information is intended to prevent malicious web sites from reading confidential information from other web sites, but also prevents web content from legitimately reading information offered by other web sites.
Under the same-origin policy, cross-site sending of information is also dangerous since it enables attacks such as cross-site request forgery (CSRF) and clickjacking. The same-origin policy cannot address these security vulnerabilities in the same way it does those around receiving of information since prohibiting cross-site sending of information would prohibit cross-site hyperlinks. Without "allow sending," there would be no "web" at all because each origin would be allowed to link only to itself.
Since the same-origin policy creates, or wants to create, blanket prohibitions on web-like features of sending and receiving information, it may not be a good fit for the access control needs of a web. Nevertheless, the same-origin policy has been applied to the Web and many Web resources now rely upon it. This section documents the same-origin policy networking restrictions that Web resources may rely upon.
The same-origin policy restricts which network messages one origin can send to another. For example, the same-origin policy allows inter-origin HTTP requests with GET and POST methods but denies inter-origin PUT and DELETE requests. Additionally, origins can use custom HTTP headers when sending requests to themselves but cannot use custom headers when sending requests to other origins.
The restrictions on reading information received from other origins is also somewhat subtle. For example, the HTML
Access-Control-Allow-Origin:* header to all responses.
TODO: Discuss how CORS and UMP lets web sites opt out of these restrictions.
Relevant reference materials:
- Same origin policy (Google Browser Security Handbook, Part 2)
- The same origin policy (archived Mozilla site as of April 21, 2008)
- November 2009 mailing list thread on ietf-http-wg
- Same Origin Policy Weaknesses by Stefano Di Paola, Alex `kuza55` K