Learn About Same Origin Policy (SOP)

Introduction

The Internet is a hub for shared resources which entails that different sites share messages, iframes, etc. in order to achieve rich and interactive functionalities on the internet. The scare on the public Internet is that not every site is safe. There is a risk of Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) and so many other vulnerabilities associated with sharing web resources on the Internet. In 1995 soon after the introduction of JavaScript, Netscape Navigator also introduced Same-Origin Policy, a policy that would ensure security on scripts and other web resources that are at the risk of being compromised. This article is a detailed analysis of the Same-Origin Policy (SOP).

The Same-Origin Policy Description

The Same-Origin Policy is a web security measure that is now being used by most modern browsers today. Its purpose was to protect how scripts accessed the DOM but over time it has been improved enough to protect sensitive parts of the entire JavaScript object. Although its implementations may differ according to the browser specifications generally its main objective is to ensure security between data that is passed between two sites from different origins.

SOP makes use of the following algorithm to determine an Origin:

Scheme Domain Port

In most modern browsers, when a request is made to another page SOP checks for the triple combination and if satisfied it sends an OK and issues the request otherwise an error or a failure response is given except for MS Internet Explorer browser which does not consider the port number in its SOP combination of the origin.

Example

The following example shows a list of different origins that are making a request to the following URI: http://www.goodcompany.com/company/companypage.html

URI ACCESSED	ACCESS?
http://www.goodcompany/company/	YES matching origin (same scheme, domain, and port)
http://www.goodcompany/company2/	YES matching origin (same scheme, domain, and port)
https://www.goodcompany/company/	NO Mismatch (different scheme) and port
http://www.au.goodcompany/company/	NO Mismatch (different domain)
http://www.goodcompany:85/company/	NO Mismatch (different port)

According to Internet Explorer implementation of the SOP: http://www.goodcompany:85/company/ would be allowed access. This is because as mentioned earlier IE does not check the port number in its definition of the origin.

Implementation of the Sam-Origin Policy (SOP)

The SOP algorithm is applied by browsers each time there is an interaction between web elements from distinct origins. This includes but not limited to:

JavaScript and the Document Object Model (DOM) this means that a page cannot access the contents of its iframe unless they share a common origin.
Cookies- a session cookie from one web application/ website cannot be sent to another page with a different origin.

Looking at the concepts of SOP without a deeper analysis has led to a lot of misconceptions about how the policy is implemented. In real-world scenarios, you may realize that certain organizations may have multiple subdomains and after having looked at the SOP algorithm described above this means that organizations will not be able to share resources on the web across different domains.

The SOP does not completely restrict the interaction between distinct origins rather the browser checks if there are any possibilities of threats if the interaction is allowed if there is none the browser allows the interaction. Usually, SOP restricts reading between distinct origins as this may result in a reading of sensitive information. This entails that you can send requests across origins but you will not be allowed to read the responses.

Declaring the ‘document.domain’ in your JavaScript will allow cross-domain interaction between sites within the same domain hierarchy.

In the same manner, SOP has its exceptions which include the ability to write on certain objects and allows reading of certain objects only in special cases e.g. you can read the length object and write on the location.href property. Using the postMessage function can allow iframes and new windows to send messages across domains.

The SOP deals with cookies differently in that they are accessible from all subdomains of a site even though technically a subdomain is considered a different origin.

Conclusion

The SOP is not entirely secure but ensuring its implementation limits the risk of exposure to vulnerabilities such as XSS and CRSF.