This writeup is unfortunately missing several important points:

### Ambient authority

All the examples explained (e.g. deleting your bank account) rely on credentials. You might ask, can we just allow web pages to send arbitrary cross-origin requests, as long as we strip cookies/client certs/etc.?

Unfortunately no. This is because of the ambient authority derived from IP addresses. That is, there are an unfortunately large number of servers (e.g. intranets, routers, printers) which will accept any request from a given IP range. Corporate intranets are perhaps the biggest one here. It would be bad if you could just issue a request fetch("go/secret-doc") and get the contents of the document from the intranet.

So even apart from credentials, the same-origin policy needs to protect cross-origin resources.

This also explains why you can easily "get around" the same-origin policy by making a request to a proxy server (like https://github.com/Rob--W/cors-anywhere ). Any requests initiated from the proxy server's IP address no longer carry ambient authority, so such a "workaround" preserves the desirable security properties.

### Dividing the world into reading/writing/embedding is not working well

If we were designing the web from scratch, you would not be able to do any operations (embedding, reading, or writing) cross-origin without an explicit CORS exemption. This is the standard that new features are held to, e.g. <script type=module>, CSS fonts, and import maps.

So it's best to think of the fact that images/iframes/classic scripts/etc. can be "embedded" cross-origin, and forms can POST cross-origin, as legacy exceptions.

This has become especially bad in light of Spectre, which essentially makes embedding === reading: if an attacker embeds an image, that brings it into the same address space, and then the attacker can read its contents using Spectre.

There are various mitigations to this. E.g.:

- Out-of-process iframes (an implementation technology), specifically for embedding iframes

- CORB (a semi-standard technology), which attempts to sniff byte sequences and avoid bringing cases like <img src="textfile.txt"> into the same process

- Gating features which are especially helpful for Spectre (like SharedArrayBuffer) behind "cross-origin isolation" (https://web.dev/why-coop-coep/) which essentially puts your website into a mode which disallows these legacy exceptions and requires opt-in even for embedding.

### Specs

> Even though same-origin policy implementations are not required to follow an exact specification, all modern browsers implement some form of it. The principles of the policy are described in RFC6454 of the Internet Engineering Task Force (IETF).

This is not accurate. The specifications for fetching these subresources and protecting from cross-origin access are very precise, and none of them are related to the IETF or RFC6454. The foundational ones are:

- https://html.spec.whatwg.org/multipage/origin.html#origin - https://fetch.spec.whatwg.org/

and then various specifications (such as HTML, or XMLHttpRequest, or Service Workers) build on top of these, e.g. by using Fetch's "cors" or "no-cors" modes.

Another special case is https://html.spec.whatwg.org/multipage/browsers.html#cross-o... which defines exactly how browsers allow certain forms of access to cross-origin windows (e.g. frames[0].postMessage()) but disallow others (e.g. frames[0].document.documentElement.outerHTML).