Same Origin Policy

From Web Security

Same-Origin Policy

There is no single same-origin policy.

General Principles

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.

Network Access

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.

Details

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 <script> element can execute content retrieved from foreign origins, which means web sites should not rely on the same-origin policy to protect the confidentiality of information in a format that happens to parse as script (e.g., JavaScript source files, JSON format, JSONP services, or JavaScript/gif polyglots). For all such resources, no loss of security would result (and much flexibility would be gained) from adding the Access-Control-Allow-Origin:* header to all responses.

Exceptions

TODO: Discuss how CORS and UMP lets web sites opt out of these restrictions.

Relevant specifications

Relevant reference materials:

Retrieved from "https://www.w3.org/Security/wiki/index.php?title=Same_Origin_Policy&oldid=265"