The Same Origin Policy is an important security mechanism that restricts how documents or scripts loaded from one origin interact with resources from another origin. The following article will give you a detailed explanation of what the same-origin policy is.
1. Purpose
It helps isolate potentially malicious documents and reduce possible attack vectors. For example, it prevents malicious websites on the Internet from running JS in the browser to read data from a third-party webmail service (where the user is logged in) or a company intranet (which prevents direct access by the attacker by: no public IP address) and forward that data to the attacker.
2. Definition
Two URLs have the same origin if their protocol, port (if specified), and host are the same. You may see it referenced as a "scheme/host/port tuple", or just a "tuple". (A "tuple" is a set of items that together form a whole - the general form of double/triple/quad/quintuple/etc.)
The following table gives an example comparison with the origin of the URL http://store.company.com/dir/page.html :
3. Cross-domain network access
The Same Origin Policy controls interactions between two different origins, such as when you use XMLHttpRequest or the <img> element. These interactions generally fall into three categories:
Cross-origin writes are generally allowed. Such as links, redirects and form submissions. Some HTTP requests require preflight.
Cross-origin embedding is generally allowed. (Examples are listed below.)
Cross-origin reads are generally not allowed, but read access is often leaked through embedding. For example, you can read the dimensions of an embedded image, the action of an embedded script, or the availability of an embedded resource.
Here are some examples of possible embedded cross-origin resources:
JavaScript with <script src=”…”></script>. Error details for syntax errors only apply to same-origin scripts.
CSS is applied with <link rel=”stylesheet” href=”…”>. Due to the loose syntax rules of CSS, cross-origin CSS requires the correct Content-Type header. The browser will prevent the stylesheet from loading if it is a cross-origin load with an incorrect MIME type and the resource does not start with a valid CSS construct.
Displayed image <img>.
<video> and the playing media <audio>.
<object>embedded and external resource <embed>.
Applied fonts with @font-face. Some browsers allow cross-origin fonts, others require same-origin fonts.
Any content embedded in an <iframe>. Sites can use the X-Frame-Options header to prevent cross-origin framing.
4. How to allow cross-domain access
Use CORS to allow cross-domain access. CORS is a part of HTTP that allows the server to specify any other hosts that the browser should be allowed to load content from.
5. How to prevent cross-domain access
To prevent cross-origin writes, check the request for an unguessable token – called a Cross-Site Request Forgery (CSRF) token. You must prevent cross-origin reads of pages that require this token.
To prevent cross-origin reads of a resource, make sure the resource is not embeddable. It is often necessary to prevent embedding, since embedding a resource will always leak some information about it.
To prevent cross-domain embedding, make sure your resource cannot be interpreted as one of the embeddable formats listed above. The browser may not respect the Content-Type header. For example, if you point a <script> tag to an HTML document, the browser will try to parse the HTML into JavaScript. You can also use CSRF tokens to prevent embedding when your resource is not the entry point to your site.
6. Cross-domain data storage access
Access to data stored in the browser, such as Web Storage and IndexedDB, is separated by origin. Each origin has its own separate storage, and JavaScript in one origin cannot read or write storage that belongs to another origin.
Cookies are defined using separate origins. A page can set cookies for its own domain or any parent domain, as long as the parent domain is not a public suffix. Firefox and Chrome use the public suffix list to determine whether a domain is a public suffix. When you set a cookie, you can limit its availability using the Domain, Path, Secure, and HttpOnly flags. When you read a cookie, you cannot see where it is set. Even if you only use a secure https connection, any cookies you see may have been set using an insecure connection.