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:
- "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.
- 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.
- 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.
It's considerably more expansive than that, and in fact covers things from before
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.