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

@martinthomson commented on this pull request.



> +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 disagree.  It's quite a compelling example in that it is forbidden for a very good reason.  (I don't know why you quoted the unrelated text about ACRH, is there a point you wanted to make there?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1818#discussion_r2039805424
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1818/review/2760765743@github.com>