What is the Same-Origin Policy (SOP)? 

In order to provide greater security, modern web applications and browsers are equipped with various mechanisms and features. One of these is the so-called Same-Origin Policy (SOP), a rule enforced by browsers to protect data exposure from one website to another.

Learn more about the same-origin policy below.

How is origin defined?

In the context of the Internet, an origin is the combination of a Uniform Resource Identifier (URI) scheme, a hostname (or domain), and a port number. 

So, let’s take the main page of our blog: https://crashtest-security.com/security-penetration-testing-blog/.

Here, the scheme is HTTPS, the host is crashtest-security.com, and the port number is 443 (the default port number for HTTPS). 

Modern browsers would consider any page with the same schemе, host, and port as having the same origin. If conversely, one of these differs, then the origin would not be considered the same. 

Using the following website (http://company-website.com/), here are a few examples of origins that would and would not be considered the same.

Whether the origin is the same or not, affects how browsers treat requests between origins.

What is the purpose of the same-origin policy?

The purpose of the SOP is to regulate whether and how origins and their resources interact. It is implemented on the browser level to guarantee no unauthorized cross-origin communication that could lead to a malicious script on one website obtaining access to sensitive data on another. Or, to put it differently, it prevents the reusing of authenticated user sessions across websites and read access to responses from different origins.

When a client sends a request to an origin, the request includes authentication details such as session cookies relevant to that origin. Imagine a user is tricked into visiting a website with a misleading domain that contains an iframe that loads the contents of the actual website. The user then proceeds to log in and, in doing so, sends the necessary authentication cookies to the actual domain via the malicious website. 

If there were no same-origin policy, the response of the actual website could be read by attackers. It would enable them to gain access to the user’s data via the Document Object Model (DOM) of the actual website and make requests on their behalf. Thanks to the same-origin policy, this is not possible.

What does the same-origin policy forbid and allow?

The SOP is sometimes erroneously understood as blocking all kinds of cross-origin requests. If that were the case, it would not be possible to serve resources between origins, and there would be no point in the existence of content delivery networks (CDN) and even the web. Neither does the SOP forbid origins from making requests to each other or writing between origins (such as submitting forms). 

Broadly speaking, the SOP allows resources to be embedded but does not allow cross-origin reading. The difference between embedding and reading is that an embedded resource is copied and becomes independent of its origin, whereas, with reading, the external origin is preserved. 

Permitted forms of embedding include HTML tags such as iframe, script, img, video, audio, link, object, embed, and form. This part of the POS can sometimes be a source of security vulnerabilities and lead to clickjacking attacks.

There are differences in how the policy and same-origin checks are implemented between browsers. The SOP application varies between technologies and resources such as cookies, JavaScript, DOM, and other APIs. That said, here are a few examples of what SOP will typically forbid:

• Cookies cannot be sent to a page with a different origin, though in this case, this only applies to pages with other domains/subdomains, whereas schema and port are not checked.
• AJAX requests such as XMLHttpRequest are not allowed under SOP, though this is possible if Cross-Origin Resource Sharing (CORS) is implemented.
• Even when embedded, JavaScript cannot read content on a website with a different origin.

Can SOP stop cyber attacks?

While SOP is highly useful in preventing several types of attacks, it has its limits and cannot contain all cross-origin threats. 

The main threats associated with exploiting origin vulnerabilities are Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and Clickjacking attacks mentioned above.

• Cross-site scripting includes injecting malicious code on the client-side to force the browser to perform specific actions and steal sessions.
• Cross-site request forgery relies on a user visiting a malicious website with an embedded code that then begins to generate requests on behalf of the user without their knowledge. 
• Clickjacking is the use of transparent buttons on top of an embedded iframe. These buttons link to malicious websites through which users’ sessions and data can be stolen or hijacked.

It would be best if you took additional actions that the SOP does not cover to prevent these attacks. See the pages associated with these attacks to learn more about avoiding them!

How to relax the same-origin policy

The policy’s strict rules can create difficulties for websites that have multiple subdomains or when two domains should be able to interact. There are ways in which cross-origin communication can be enabled in a controlled manner in such situations.

Cross-origin resource sharing (CORS)

One common way of relaxing SOP is through cross-origin resource sharing (CORS). CORS enables the sharing of external resources through the HTTP Access-Control-Allow-Origin response header. 

A browser sends a request header to a different origin, and the server provides the necessary instructions in its response header. If according to the instructions, the request from this origin is permissible, the browser allows the server response. If not, the answer is not shared by the browser. 

CORS also offers the possibility to perform a preflight request, also known as an OPTIONS request. The preflight request asks the server whether it will permit the client to perform a cross-domain call, particularly one that includes headers or other methods that can modify data. If the server allows this, then the actual request can proceed.

JavaScript document.domain 

JavaScript allows for different origins to interact, albeit in a limited way. This option applies to origins such as subdomains that share a domain hierarchy. It enables them to declare their origin as the domain or superdomain under which they are located. This also applies to scripts that operate on such pages.

For example, using this method, subdomains such as store.example.com and login.example.com can declare their domain as being:

document.domain = "example.com";

The website at example.com must use the same setting to complete the process. Once this is applied, resource sharing between these origins is enabled. 

Note that port and schema limitations under SOP are not removed in this scenario and must still match.

JSON with padding (JSONP)

JSONP also offers a way of going around SOP. This workaround uses the <script> tag and the fact that the policy allows JavaScript to retrieve and execute resources from different domains. 

Therefore, cross-origin resources can be shared by using the tag’s src attribute, which specifies the URL of an external script file. In this way, a resource can be loaded that returns a JSONP payload. The resource is then processed via the included callback function and can be accessed. 

FAQ

Why is the same-origin policy required?

SOP is a browser policy that protects domains from cross-origin interferences. It regulates read access to resources of one domain from another via JavaScript. The policy does not stop resources from being embedded, making it possible for domains to interact, albeit in specific limited ways.

Is SOP enough to stop cross-origin attacks?

No, the policy cannot prevent attacks such as cross-site scripting, cross-site request forgery, or clickjacking. However, it offers good protection against cross-origin attempts at reusing authenticated sessions and reading resources from another origin.

Can SOP be relaxed?

Yes, several approaches exist that allow the policy to be loosened and resources to be shared between domains. This includes CORS, document, domain, JSONP, and others.