Why same origin policy

Although same-origin policy is an important browser security feature that provides significant protection against malicious scripts, it is far from perfect. In other cases the policy is too restrictive and tangles the workflow of the web application.

Engineers introduced a standard called Cross-Origin Resource Sharing as a way to relax the same-origin policy's restrictions. In this case, the browser adds an Origin: header describing the origin from where the request has been initiated.

Once the request is received the server tells the browser if the CORS request is valid by appending the Access-Control-Allow-Origin header to the response. Here is an example to make things clear.

It should look like this:. If the check fails, the response is blocked immediately. Also, one important note is that the Access-Control-Allow-Origin header supports only a single origin. This means you cannot specify multiple websites as the value of this header e. This is a bad idea unless you want anyone to consume your restful API. Any request that is not considered Simple i.

This is because the browser sends a preflight request before the original request to make sure that the original request is acceptable to the server. Below is an example:.

Once the server receives the preflight request it responds with headers which tell if the preflight request has been accepted:. Also, it will contain the Origin header similar to the Simple requests. CORS is just one method to relax same-origin policies. Basically, content received from one website is allowed to read and modify other content received from the same site but is not allowed to access content received from other sites.

Another question is: what is the purpose of Origin header and how do cross domain requests still exist? Why doesn't it influence the security or the same origin policy? Assume you are logged into Facebook and visit a malicious website in another browser tab. Without the same origin policy JavaScript on that website could do anything to your Facebook account that you are allowed to do. For example read private messages, post status updates, analyse the HTML DOM-tree after you entered your password before submitting the form.

But of course Facebook wants to use JavaScript to enhance the user experience. So it is important that the browser can detect that this JavaScript is trusted to access Facebook resources. Now replace Facebook with your online banking website, and it will be obvious that this is an issue. I know it means that when getting a resource from another domain say a JS file it will run from the context of the domain that serves it like google analytics code , which means it can't modify the data or read the data on the domain that "includes the resource".

The same origin policy is not enforced for all requests. Posting forms and linking to other domains is possible, too. Frames and iframes way display information from other domains but interaction with that content is limited. There are some approaches to allow XMLHttpRequest ajax calls to other domains in a secure way, but they are not well supported by common browsers. The information, which shall be sent to another domain, is encoded in the URL as parameters. The returned JavaScript consists of a function call with the requested information as parameter:.

Cross Site Scripting is a vulnerability that allows an attacker to inject JavaScript code into a website, so that it originates from the attacked website from the browser point of view.

This can happen if user input is not sufficiently sanitised. For example a search function may display the string "Your search results for [userinput]". If [userinput] is not escaped an attacker may search for:. The browser has no way to detect that this code was not provided by the website owner, so it will execute it. Nowadays cross site scripting is a major issue, so there is work done to prevent this vulnerability.

Most notable is the Content Security Policy approach. For every form on bank. So if evil. But then, what prevents the evil. This is where the SOP comes into play.

What if implementations had a rule like: "allow any request, but only send cookies on current domain XHR"? Wouldn't that be simpler? But that would still allow for another type of attack: when authentication is based not on cookies, but on source IP of the request!

For example, you are in your company's intranet and from there you can access an internal server, which is not visible from the outside and serves secret data. The only thing that can't ever be allowed is reading the result of such request back in JavaScript, as that would beat the synchronizer token pattern.

From MDN :. However, read access is often leaked by embedding. 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 and thus possibly if the user is logged in or not on a given domain.

It turns out that Google Analytics can, in theory, do anything they want to your users. The X-Frame-Options header allows you to lock frames down even further to protect against things like Clickjacking.

The Origin header is used by a mechanism named "Cross-Origin Resource Sharing" which allows sites to grant limited exceptions to same-origin policy for safe cross-site interaction. Basically, when you try to make an XMLHttpRequest to a different domain, the browser will do one of two things :. In either case, the browser appends an Origin header which tells the target site who's calling. It's sort of like the Referer header, but required and more strictly specified to ensure proper security.

If it doesn't, the browser simply discards the response and returns an error to the Javascript callback. MDN goes into great detail 1 2 on what goes on under the hood in both scenarios as well as what other headers the target system can set to further relax the security in a controlled fashion.

Allowing access to custom HTTP headers you're setting. When you read a cookie, you cannot see from where it was set. Even if you use only secure https connections, any cookie you see may have been set using an insecure connection. Skip to main content Skip to search Skip to select language Web technology for developers Web security Same-origin policy Change language.

Internet Explorer has two major exceptions to the same-origin policy: Trust Zones If both domains are in the highly trusted zone e. Port IE doesn't include port into same-origin checks. These exceptions are nonstandard and unsupported in any other browser.

These interactions are typically placed into three categories: Cross-origin writes are typically allowed. Examples are links, redirects, and form submissions. Some HTTP requests require preflight. Cross-origin embedding is typically allowed. Examples are listed below. Cross-origin reads are typically disallowed, but read access is often leaked by embedding.

For example, you can read the dimensions of an embedded image, the actions of an embedded script, or the availability of an embedded resource. Error details for syntax errors are only available for same-origin scripts.

Fonts applied with font-face. Some browsers allow cross-origin fonts, others require same-origin. Sites can use the X-Frame-Options header to prevent cross-origin framing. You must prevent cross-origin reads of pages that require this token. To prevent cross-origin reads of a resource, ensure that it is not embeddable. It is often necessary to prevent embedding because embedding a resource always leaks some information about it.