manual".
+The Fetch standard enforces some of the mechanisms that constitute the Same Origin Policy (SOP), +which is a critical aspect of web security. Specifically, Fetch imposes SOP restrictions on network +access. + +
In a nutshell, when a user accesses a certain origin using their browser or other user agent, +they don't expect that the user agent implicitly grants that origin full access to +their network, which could, for example, be an intranet, despite the user agent itself having that +access. + +
To keep this information from leaking, SOP restricts requests that come from the visited +origin to only target that same origin, while allowing a few mechanisms for an origin +to access cross-origin data safely. + +
When invoking fetch, it's important for an author of a spec to understand whether +the spec requires access cross-origin data, and to setup the requests appropriately as described +here. + +
The main way to access cross-origin data is via the cors protocol, described in detail in +this standard. CORS (Cross Origin Resource Sharing) is built on the principle that origins that want +to access data from other origins need to identify themselves, and get explicit approval from the +server to access that data, thus not relying on any implict trust given to the user agent or to the +machine the user agent is installed on. + +
This is done by sending the `Origin` header with CORS-enabled
+requests, and expecting a matching `Access-Control-Allow-Origin`
+response header in return.
+
+
The CORS-preflight fetch mechanism extends this further, by sending that identification +handshake as a separate request, prior to sending the payload of the request itself. + +
For any new spec invoking fetch to access cross-origin rersources, CORS should be
+the only option. This has been implemented in multiple newer standards such as web fonts and module
+scripts. To apply the cors protocol, set the request's mode
+to "cors", as described in the
+Setting up a request section.
+
+
Embedding cross-origin resources, without the ability to read them, existed prior to CORS. +Cross-origin images, scripts, stylesheets & media are embeddable in a document without +the embedding origin identifying themselves and receive explicit confirmation. + +
To maintain backwards compatibility, this form of fetching is still supported. Instead of +restricting the network access, the embedder is restricted in what they are allowed to do with the +response. They can embed it in their document and present it to the user, but this has +to be done in a way that's opaque to the embedding origin. Only the user should have access to the +resource, not the embedder. + +
This mechanism of fetching should not be used in new specs. In addition, specs should be careful
+not to accidentally expose data that was retrieved using "no-cors", e.g., by supplying
+new mechanisms to read images without checking for this.
+
+
Note that this is the default request mode, so new specs should be deliberate about setting the
+request's mode to "cors" or to "same origin", as
+described in the Setting up a request section, and also make
+sure that this is aligned and communicated with servers that deliver this type of resource.
+
+
Due to the leaky nature of no-CORS requests, resources can further protect themselves by
+providing a `Cross-Origin-Resource-Policy` header (CORP). By
+supplying the appropriate CORP header, a resource can opt out from being embedded by a different
+site or origin. For example, this can be used to protect an image's natural dimensions from
+being read by an embedder.
+
+
This protection is especially important when exposing powerful features to the web platform, that
+gain enough access to the underlying platform to read cross-origin resources using attacks like
+Spectre. This category of features, e.g., SharedArrayBuffer or high-resolution
+timestamps, cannot be used together with the default policy that allows cross-origin content to be
+embedded.
+
+
Instead, the embedder must use
+cross-origin isolation, using the
+`Cross-Origin-Embedder-Policy` header to restrict embedding of
+cross-origin resources only to resources that explicitly allow this.
+
+
Note that CORP and cross-origin isolation are not designed to be a "lighter version of CORS". +Their purpose is to restrict embedding of existing resources that are normally embeddable without +CORS, in order to enable safe usage of powerful platform features. + +
Other specifications should consider requiring CORP if they expose a powerful platform feature,
+regardless of whether they themselves invoke fetch. To guard a feature based on this
+protection, check the Document's cross-origin isolated capability.
+
+
Beside the protections for the resource's data itself, the Fetch standard enforces restrictions +on accessing timing information associated with the fetch. This timing information +includes multiple milestones in the fetch process, such as receiving the first redirect or beginning +the DNS lookup, as described in the Resource Timing spec. [[RESOURCE-TIMING]] + +
This information, like any other information, is protected by the Same-Origin Policy, and
+is available by default for same-origin resources only. A server delivering a cross-origin resource
+can relax this restriction by including the `Timing-Allow-Origin` header in the
+response.
+
+
The `Timing-Allow-Origin` (TAO) header is orthogonal to CORS, as CORS allows sharing
+information about the resource, while TAO allows sharing information about the particular fetch,
+and in particular only timing information.
+
+
Note that the TAO status does not persist with a response when it enters the cache +or forwarded using a Service Worker. TAO is valid for a single Fetch, and only enables +sharing information about the fetch that is clearly timing related. + +
Specifications invoking fetch should generally not worry about timing information,
+however, specs that expose new timing information (e.g., new additions to
+Resource Timing) need to consult these guidelines to see if the new information needs
+to be protected by `Timing-Allow-Origin`. This kind of addition would likely require
+additions to the Fetch standard itself.
+
+
Thanks to