If browser cookies aren't shared between different websites, then why is Same origin Policy useful?

Question

I'm a beginner to Web security and I recently started reading about Same Origin Policy and it's usefulness in preventing a malicious website from interacting with a secure website being used by a user. (For example, a bank website that a user has logged in).

My question is, if the Bank website (or any other legitimate one) uses cookies to authenticate important user actions, and the cookies are inaccessible by other websites, then how is the Same Origin Policy useful since the cookies already have a security mechanism that prevents other websites from accessing them?

Answer 1

the cookies are inaccessible by other websites

I think the core of your confusion is here. Specifically, I suspect that you think this means "other websites can't use the bank website's cookies". That is wrong. What it means is "other website's can't read the bank website's cookies". Any request that any site sends to your bank website will still have the bank website's cookies attached even though the requesting origin doesn't know what those cookies are or even whether they exist. The browser automatically attaches domain X's cookies whenever a request is sent to domain X, no matter where from.

Or at least, that used to be the case, and is how cookies were standardized initially. These days, there's an update to the cookie standard specifying "samesite" behavior, which prevents cookies from being automatically added with some cross-origin requests. There are three reasons for emphasizing some there, though:

1. "Origin" in the sense of "same-origin" and "site" in the sense of "samesite" are not the same thing. Origin only matches if the domain, protocol, and port are an exact match. Site ignores protocol and port and requires that only part of the domain match (specifically, both domains must have a common suffix that is at least one level deeper than a "public suffix"). Thus e.g. https://security.stackexchange.com and http://stackexchange.com are different origins by all three metrics, but are considered same site for cookies.
2. Samesite behavior is optional and can be turned off (by the site that sets the cookie). In some cases - where sites are expected to handle requests originating from other sites (any other sites, you don't get to choose) and those requests need to have cookies - it must be turned off.
3. Samesite is still relatively new, and not universally adopted. While the up-to-date versions of all major browsers support it, minor browsers (if they aren't just a wrapper around Gecko or WebKit/Blink) might not support it yet, deprecated browsers (even so recently deprecated as Internet Explorer) may never get support, and some people use obsolete browser versions (e.g. if they have old smartphones that haven't gotten updates in years). This is especially relevant because samesite initially defaulted to off - sites had to opt in - and only years later switched the default level to "Lax", so many sites that get samesite protection in modern browser versions don't have it in browsers from just a few years ago even if the browser does support samesite when set explicitly.

Incidentally, this whole "automatically attach destination's cookies no matter where request originates" thing is also the main source of cross-site request forgery (CSRF) attack risk. SOP doesn't stop CSRF - CSRF is specifically an attack that works around the restriction of SOP - but most of the CSRF mitigations rely on SOP in order to be viable.

---

I was under the assumption that Same Origin Policy is mainly meant for Ajax requests and JavaScript calls

It's considerably more expansive than that, and in fact covers things from before XMLHttpRequest or fetch - the APIs underlying modern "AJAX" - existed, or at least supported cross-origin requests at all. For example, it also applies to frames and iframes (a parent page can see and modify the contents of a child, and a child of the parent, only if they have the same origin; otherwise, child and parent can each navigate the other but can't access their contents) and child windows (if same-origin, a parent page can access and modify a child page through the Window object returned by open and the child page can access and modify the parent page through the opener property; if they aren't same-origin then again almost all access in both directions is lost). It applies in slightly odd ways to scripts (domain X can't read a script coming from domain Y, but it can execute it; this is how JSONP worked before the vastly superior CORS replaced it), and also to stylesheets, images, and some other content.

Basically, anything in a browser where one origin can interact with another origin, the degree of access granted through that interaction is either defined in or specifically in response to the restrictions of same-origin policy.

---

Finally, consider that cookies are not the be-all and end-all of authenticated requests. There are other forms of authentication, or at least authorization, which are not cookie-based, and which the browser automatically uses when a request is sent. These include:

• HTTP Basic and Digest authentication (old-school user-agent-based rather than website-based username+password auth)
• Kerberos authentication (used on e.g. Windows domains for authenticating to intranet sites)
• Mutual TLS (TLS with client certificates, which are often sent automatically if available)
• IP filtering (authorization based purely on having the right source IP)
• Network filtering (authorization based on being on the correct network, usually implying physical access or VPN and possibly also implying IPSec)
• Binding to loopback only (the server isn't even visible except to local clients)

and so forth. All of these are relevant for cross-origin requests (including CSRF but also fetch and iframes and so on) and don't rely on cookies at all.

Answer 2

I believe when you say "and the cookies are inaccessible by other websites" -- that is in itself the Same Origin Policy. SOP means that if you visit malicious.com and it loads a resource (such as an image) from yourbank.com, the JavaScript on the malicious.com page can't access the valid session cookies sent to yourbank.com in the resource load.

I'll quote from Wikipedia's article as it does a good job addressing your situation:

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.

You may also be interested in PortSwigger's article on CORS and SOP. This article will help give more info. Check out this quote:

The same-origin policy is a restrictive cross-origin specification that limits the ability for a website to interact with resources outside of the source domain. The same-origin policy was defined many years ago in response to potentially malicious cross-domain interactions, such as one website stealing private data from another. It generally allows a domain to issue requests to other domains, but not to access the responses.

This is a browser security mechanism, not a website security mechanism. So, for example, Firefox has SOP configured by default.