cors-anywhere

"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).