From 987b95d42a25b67d6dce4bdd844fe61792d86937 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 28 Jan 2025 10:53:13 +0000 Subject: [PATCH 1/8] Add prose about CORS, cross-origin isolation and TAO --- fetch.bs | 100 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) diff --git a/fetch.bs b/fetch.bs index 4b1f0c2ca..0ce7631c9 100644 --- a/fetch.bs +++ b/fetch.bs @@ -9062,6 +9062,106 @@ done only by navigations). The fetch controller is also used to redirect mode set to "manual". +

Same-origin policy when using fetch

+ +

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. + +

In addition, the user agent may include footprint that identifies the user to the origin, +explicitly using cookies or client certificates, or implicitly using, for example, the user-agent's +IP address. + +

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. + +

Cross-origin resource sharing (CORS)

+ +

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. + +

No-CORS requests

+ +

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. However, specs should be written with +the notion that no-CORS resources exists, and the new spec should not grant origins the ability to +read their contents. + +

CORP & Cross-origin isolation

+ +

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 embedded. + +

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. + +

Accessing timing information (TAO)

+ +

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. + +

Acknowledgments

Thanks to From ede95bc72a0b9c2448846fdeaa8018e6d3da13f7 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 28 Jan 2025 11:05:50 +0000 Subject: [PATCH 2/8] Fix ref --- fetch.bs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fetch.bs b/fetch.bs index 0ce7631c9..e15fe6f0f 100644 --- a/fetch.bs +++ b/fetch.bs @@ -9126,8 +9126,9 @@ being read by an embedded.

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. +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 From 8f67c89ace6358ae6f48c78ceaf9bd24f78235c0 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 28 Jan 2025 11:07:29 +0000 Subject: [PATCH 3/8] Fix ref --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index e15fe6f0f..3d4f11149 100644 --- a/fetch.bs +++ b/fetch.bs @@ -9126,7 +9126,7 @@ being read by an embedded.

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 +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. From 6d70c4cae540b60df68265b32d8dd5beda6c7fd3 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 28 Jan 2025 20:11:22 +0000 Subject: [PATCH 4/8] Update fetch.bs Co-authored-by: Dominic Farolino --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index 3d4f11149..23c8314fc 100644 --- a/fetch.bs +++ b/fetch.bs @@ -9078,7 +9078,7 @@ explicitly using cookies or client certificates, or implicitly using, for exampl IP address.

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 +origin to only target that same origin, while allowing a few mechanisms for an origin to access cross-origin data safely.

Cross-origin resource sharing (CORS)

From d38a22870ebb801668cee195283049d0d4862f4a Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 28 Jan 2025 20:12:17 +0000 Subject: [PATCH 5/8] Update fetch.bs Co-authored-by: Dominic Farolino --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index 23c8314fc..8f646ab0b 100644 --- a/fetch.bs +++ b/fetch.bs @@ -9122,7 +9122,7 @@ read their contents. 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 embedded. +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 From 5a0d77b47848037275e8a6a2e2186df35bbdf598 Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Tue, 28 Jan 2025 20:12:25 +0000 Subject: [PATCH 6/8] Update fetch.bs Co-authored-by: Dominic Farolino --- fetch.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fetch.bs b/fetch.bs index 8f646ab0b..7734b86b3 100644 --- a/fetch.bs +++ b/fetch.bs @@ -9126,7 +9126,7 @@ 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 +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. From 5062a487c01ccd6a7a0b1006bc6f1eaab8a4c88e Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Wed, 29 Jan 2025 09:05:27 +0000 Subject: [PATCH 7/8] Add more references for spec writers --- fetch.bs | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/fetch.bs b/fetch.bs index 7734b86b3..02e1624c6 100644 --- a/fetch.bs +++ b/fetch.bs @@ -9073,14 +9073,14 @@ they don't expect that the user agent implicitly grants that origin their network, which could, for example, be an intranet, despite the user agent itself having that access. -

In addition, the user agent may include footprint that identifies the user to the origin, -explicitly using cookies or client certificates, or implicitly using, for example, the user-agent's -IP address. -

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. +

Cross-origin resource sharing (CORS)

The main way to access cross-origin data is via the cors protocol, described in detail in @@ -9098,7 +9098,9 @@ handshake as a separate request, prior to sending the payload of the request its

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. +scripts. To apply the cors protocol, set the request's mode +to "cors", as described in the +Setting up a request section.

No-CORS requests

@@ -9116,6 +9118,11 @@ resource, not the embedder. the notion that no-CORS resources exists, and the new spec should not grant origins the ability to read their contents. +

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. +

CORP & Cross-origin isolation

Due to the leaky nature of no-CORS requests, resources can further protect themselves by @@ -9140,7 +9147,8 @@ Their purpose is to restrict embedding of existing resources that are normally e 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. +regardless of whether they themselves invoke fetch. To guard a feature based on this +protection, check the Document's cross-origin isolated capability.

Accessing timing information (TAO)

@@ -9162,6 +9170,12 @@ and in particular only timing information. 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. +

Acknowledgments

From 3ded9cdb70129419a285d6ed9dcd179f1df3891b Mon Sep 17 00:00:00 2001 From: Noam Rosenthal Date: Wed, 29 Jan 2025 09:08:13 +0000 Subject: [PATCH 8/8] Reword no-cors section a bit --- fetch.bs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fetch.bs b/fetch.bs index 02e1624c6..4ebca383b 100644 --- a/fetch.bs +++ b/fetch.bs @@ -9114,9 +9114,9 @@ restricting the network access, the embedder is restricted in what they are allo 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. However, specs should be written with -the notion that no-CORS resources exists, and the new spec should not grant origins the ability to -read their contents. +

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