Same-origin policy
In computing, the same-origin policy (SOP) is a concept in the web application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's (DOM).
This mechanism bears a particular significance for modern web applications that extensively depend on HTTPScookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions. A strict separation between content provided by unrelated sites must be maintained on the client-side to prevent the loss of data confidentiality or integrity.
The same-origin policy applies only to scripts. This means that resources such as images, CSS, and dynamically-loaded scripts can be accessed across origins via the corresponding HTML tags (with fonts being a notable exception). Attacks take advantage of the fact that the same origin policy does not apply to HTML tags.
History[edit]
The concept of same-origin policy was introduced by Netscape Navigator 2.02 in 1995,[1] shortly after the introduction of JavaScript in Netscape 2.0.[2][3] JavaScript enabled scripting on web pages, and in particular programmatic access to the Document Object Model (DOM).
The policy was originally designed to protect access to the DOM, but has since been broadened to protect sensitive parts of the global JavaScript object.
Implementation[edit]
All modern browsers implement some form of the same-origin policy as it is an important security cornerstone.[4] The policies are not required to match an exact specification[5] but are often extended to define roughly compatible security boundaries for other web technologies, such as Microsoft Silverlight, Adobe Flash, or Adobe Acrobat, or for mechanisms other than direct DOM manipulation, such as XMLHttpRequest.
Read access to sensitive cross-origin responses via reusable authentication[edit]
The same-origin policy protects against reusing authenticated sessions across origins. The following example illustrates a potential security risk that could arise without the same-origin policy. Assume that a user is visiting a banking website and doesn't log out. Then, the user goes to another site that has malicious JavaScript code that requests data from the banking site. Because the user is still logged in on the banking site, the malicious code could do anything the user could do on the banking site. For example, it could get a list of the user's last transactions, create a new transaction, etc. This is because, in the original spirit of a world wide web, browsers are required to tag along authentication details such as session cookies and platform-level kinds of the Authorization request header to the banking site based on the domain of the banking site.
The bank site owners would expect that regular browsers of users visiting the malicious site do not allow the code loaded from the malicious site access the banking session cookie or platform-level authorization. While it is true that JavaScript has no direct access to the banking session cookie, it could still send and receive requests to the banking site with the banking site's session cookie. Same Origin Policy was introduced as a requirement for security-minded browsers to deny read access to responses from across origins, with the assumption that the majority of users choose to use compliant browsers. The policy does not deny writes. Counteracting the abuse of the write permission requires additional CSRF protections by the target sites.
Corner cases[edit]
The behavior of same-origin checks and related mechanisms is not well-defined in a number of corner cases such as for pseudo-protocols that do not have a clearly defined host name or port associated with their URLs (file:, data:, etc.). This historically caused a fair number of security problems, such as the generally undesirable ability of any locally stored HTML file to access all other files on the disk, or communicate with any site on the Internet.
Lastly, certain types of attacks, such as DNS rebinding or server-side proxies, permit the host name check to be partly subverted, and make it possible for rogue web pages to directly interact with sites through addresses other than their "true", canonical origin. The impact of such attacks is limited to very specific scenarios, since the browser still believes that it is interacting with the attacker's site, and therefore does not disclose third-party cookies or other sensitive information to the attacker.
Attacks[edit]
Even when same-origin policy is in effect (without being relaxed by Cross-Origin Resource Sharing), certain cross-origin attacks can be performed. WebRTC can be used to find out the internal IP address of a victim. If attempting to connect to a cross-origin port, responses cannot be read in face of same-origin policy, but a JavaScript can still make inferences on whether the port is open or closed by checking if the onload/onerror event fires, or if we get a timeout. This gives opportunities for cross-origin portscanning. Further, JavaScript snippets can use techniques like cross-site leaks to exploit long-standing information leakages in the browser to infer information about cross-origin.