- From: Anne van Kesteren <notifications@github.com>
- Date: Fri, 04 Apr 2025 06:40:13 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/1818/review/2743022059@github.com>
@annevk requested changes on this pull request. If we are going to redefine what it means to extend the same-origin policy we should not do that here. > +there are cases where information might be spoofed by a malicious client. + +<p id=why-sec-fetch-dest-is-sec class=example>The [:Sec-Fetch-Dest:] <a>header</a> might be used in +<a for=/>requests</a> both with or without <a for=/>credentials</a>. The decisions that a server makes using +[:Sec-Fetch-Dest:] can be security-relevant for an honest user agent, even for <a for=/>requests</a> +without credentials. + + +<h4 id=sec-not-ok>Reasons not to use a `<code>Sec-</code>` prefix</h4> + +<p>That a <a>header</a> value might be needed to answer a <a>CORS-preflight request</a> is +<em>not</em> a sufficient reason to use a `<code>Sec-</code>` prefix; all <a>CORS-preflight +requests</a> include [:Access-Control-Request-Method:], which is [=forbidden +request-headers|forbidden=]. Any <a for=/>headers</a> that a fetch caller sets will not be set on a +<a>CORS-preflight request</a> made by an honest user agent; instead, these are listed in +[:Access-Control-Request-Headers:]. I'm not sure this is a compelling example as these were introduced prior to the introduction of the prefix. > + + +<h4 id=sec-not-ok>Reasons not to use a `<code>Sec-</code>` prefix</h4> + +<p>That a <a>header</a> value might be needed to answer a <a>CORS-preflight request</a> is +<em>not</em> a sufficient reason to use a `<code>Sec-</code>` prefix; all <a>CORS-preflight +requests</a> include [:Access-Control-Request-Method:], which is [=forbidden +request-headers|forbidden=]. Any <a for=/>headers</a> that a fetch caller sets will not be set on a +<a>CORS-preflight request</a> made by an honest user agent; instead, these are listed in +[:Access-Control-Request-Headers:]. + +<p id=sec-purpose-no-sec class=example>The [:Sec-Purpose:] field tells a server that a +<a for=/>request</a> is speculative. A server might choose to avoid triggering side-effects while +processing such a request, such as suppressing the recording of page view metrics. Making this a +<a>forbidden request-header</a> has no security-relevant purpose and the `<code>Sec-</code>` prefix +is therefore unnecessary. This is a redefinition of the threat model. See https://github.com/w3c/resource-hints/issues/74#issuecomment-473806820 for a discussion of this header. Sending new headers across origin without preflight and without a `Sec-` prefix is an extension of the same-origin policy. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/1818#pullrequestreview-2743022059 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/pull/1818/review/2743022059@github.com>
Received on Friday, 4 April 2025 13:40:17 UTC