Same-origin policy SOP domain restriction rule (same source policy)

The domain restriction rule (Same Origin Policy, translated from English - “Principle of the same source”) is an important security concept for some client-side programming languages, such as JavaScript. The policy allows scripts on the pages of one site to access methods and properties of each other without restrictions, but prevents access to most methods and properties for pages on different sites. Identical sources are those that coincide with three signs:

1. domain name;
2. port;
3. protocol.

The same-origin policy defines how a document or script loaded from one source (origin) can interact with a resource from another source (origin). This is a critical security mechanism for isolating potentially dangerous documents.

Definition of origin

Two pages have the same origin (source) if the protocol, port (if specified), and host are the same for both pages. From time to time, you can see this as the "scheme / host / port tuple" (where "tuple" translates as a tuple or record is a set of three components that together form a single entity).

The following table gives examples of origin comparisons with the URL http://store.company.com/dir/page.html:

See also origin definition for file: URLs.

Checklist

For illustration, the following table gives an overview of typical checks for comparison with the example URL "http://www.example.com/dir/page.html".

Origins inheritance

The contents of the about: blank and javascript: URLs inherit the source from the document that loads the URL, since the URL itself does not provide any information about the origin. data: URLs get a new, empty, security context.

Note: Before Gecko 6.0, dataURL, the inherited security context of the current page in the browser window, if the user enters dataURL into the address bar.

IE Exceptions

Internet Explorer has two major exceptions when it comes to the same origin policy.

• Target zones: if both domains are in a zone of high confidence, for example, corporate domains, then the same restrictions of origin do not apply
• Port: IE does not include the port in the Same Origin components, therefore http://company.com:81/index.html and http://company.com/index.html are considered from the same source and do not apply restrictions

These exceptions are non-standard and not supported in any other browser, but would be useful when developing an application for a Windows RT-based web application (or) based on IE.

Change of origin

The page may change its origin with some restrictions. The script can set the value of document.domain for the current domain or super domain of the current domain. If it sets it to the superdomain of the current domain, the shorter domain is used for subsequent origin checks. For example, suppose the script in document http://store.company.com/dir/other.html executes the following statement:

 document.domain = "company.com"; 

After completing this statement, the page can pass the verification of origin http://company.com/dir/page.html (provided that it http://company.com/dir/page.html sets the document.domain value to "company.com" to indicate that she wants to allow this - see document.domain (for more). However, company.com may not install, document.domain to othercompany.com, which is not a company.com superdomain.

The port number is stored separately by the browser. Any call to the setter, including document.domain = document.domain, causes the port number to be overwritten null. Therefore, one cannot do company.com:8080 a conversation with company.com using only setting document.domain = "company.com" in the first one. It should be set as for both port numbers null.

Note. When using document.domain to allow a subdomain to contact its parent safely, you need to set document.domain to have the same value in both the parent domain and the subdomain. This is necessary, even if it simply returns the parent domain to its original value. Failure to do so may result in permission errors.

Internet access

Policies of the same origin control interactions between two different sources, for example, when you use the XMLHttpRequest or <img> element. These interactions are usually divided into three categories:

• Normally entries with a cross-start are allowed. Examples are links, redirects, and form submissions. Some rarely used HTTP requests require pre-checking.
• Cross- deployment is usually allowed. Examples are given below.
• Cross-origin reads are generally not allowed, but read access often leaked attachments. For example, you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

Here are some examples of resources that can be embedded in cross-origin:

• Javascript with <script src = "..."> </ script>. Error messages for syntax errors are available only for scenarios of the same origin.
• CSS with <link rel = "stylesheet" href = "...">. Due to the relaxed CSS syntax rules, cross-started CSS requires the correct Content-Type header. The restrictions depend on the browser: IE, Firefox, Chrome, Safari (scroll down to CVE-2010-0051) and Opera.
• Images from <img>. Supported image formats include PNG, JPEG, GIF, BMP, SVG, ...
• Multimedia files with <video> and <audio>.
• Plugins with <object>, <embed> and <applet>.
• Fonts with @ font-face. Some browsers allow you to use fonts with a cross-original, others - fonts of the same origin.
• Anything with <frame> and <iframe>. The site can use the X-Frame-Options header to prevent this form of interaction with the cross-start.

How to allow access to cross-connect

Use CORS to allow cross-start access.

How to block access to cross-connect

• To prevent cross-entries, check for an unrecognized token in the request, known as a cross-site request (CSRF) token. You must prevent cross-reads of pages that know this token.
• To prevent cross-reading of a resource, make sure that it is not embedded. It is often necessary to prevent deployment, because investing a resource always leaks some information about it.
• To prevent embedding in the cross-start, make sure that your resource cannot be interpreted as one of the embedded formats listed above. In Content-Type most cases the browser does not comply. For example, if you specify a <script> tag in an HTML document, the browser will attempt to parse the HTML as JavaScript. When your resource is not the entry point to your site, you can also use the CSRF token to prevent deployment.

Access to the Cross-origin API

JavaScript APIs such as iframe.contentWindow, window.parent, window.open, and window.opener allow documents to directly link to each other. If the two documents do not have the same origin, these links provide very limited access to Window and Location objects, as described in the next two sections.

To communicate between documents from different sources, use window.postMessage.

Window

Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window.

Window Access to properties is available for several reasons:

Some browsers allow access to more properties than the specification allows.

Location

Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-location.

Location Access to properties is available for several reasons:

Some browsers allow access to more properties than the specification allows.

Access to data storage with cross access

Access to data stored in the browser, such as localStorage and IndexedDB, is divided by origin. Each lineage gets its own separate repository, and JavaScript in one source cannot read or write to storage belonging to another source.

Cookies use a separate definition of origin. A page can set cookies for its domain or any parent domain if the parent domain is not a public suffix. Firefox and Chrome use a public suffix list to determine if a domain is a public suffix. Internet Explorer uses its own internal method to determine if a domain is a public suffix. The browser will make a cookie available for this domain, including any subdomains, regardless of which protocol (HTTP / HTTPS) or port is used. When you set a cookie, you can limit its accessibility using the Domain, Path, Secure and Http-Only flags. When you read a cookie, you cannot see where it was installed from. Even if you only use secure https connections, any cookie you see can be set up using an insecure connection.

see also

• Same origin policy for file: URI
• Policy of the same origin in the W3C