Re: [whatwg/fetch] Add usage advice for Sec- (PR #1818)

@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>