manual".
+Sec-` prefixFetch defines a set of forbidden request-headers and the `Sec-` prefix for
+headers that are intended to be exclusively generated by the user agent. Callers of
+fetch cannot set these values when making requests.
+
+
This prohibition provides servers some assurance that a browser produced these +headers. However, this assurance is limited to request that could only have been +generated by an honest user agent. Other types of application–including malicious browsers–can +provide any value for any header. + +
Forbidden request-headers are most useful where servers need to make security +decisions about the value of those headers on requests that also include +credentials. + +
Whether the value of forbidden request-headers can be trusted to be accurate then depends +on a judgment about the trustworthiness of the entity that is presenting +credentials. Any client or user agent acting on behalf of a malicious user might +present falsified information if that serves the user's interests. + + +
Sec-` prefixIt is not enough that a value originates from a user agent to justify the use of
+`Sec-`, a server needs to depend on the accuracy of the information in the
+header. When deciding whether to add a new header to the set of forbidden
+request-headers by adding a `Sec-` prefix to its name, consider first whether a
+server might make a security decision that relies on an accurate header value.
+
+
A [:Connection:] header with a value of
+`close` causes the server to close a connection after producing a
+response. This is not a capability that fetch is intended to enable, making this
+a natural choice for a forbidden request-header.
+
+
The [:Sec-WebSocket-Key:] header is used on a
+`GET` request made during the WebSocket handshake. Using the
+`Sec-` prefix for [:Sec-WebSocket-Key:] ensures that a server that does not check other
+headers (such as [:Upgrade:]) cannot be duped into
+believing that a fetch is a WebSocket connection attempt.
+
+
Routine security checks can be aided as a result of having more accurate information, even if +there are cases where information might be spoofed by a malicious client. + +
The [:Sec-Fetch-Dest:] header might be used in +requests both with or without credentials. The decisions that a server makes using +[:Sec-Fetch-Dest:] can be security-relevant for an honest user agent, even for requests +without credentials. + + +
Sec-` prefixThat a header value might be needed to answer a CORS-preflight request is
+not a sufficient reason to use a `Sec-` prefix; all CORS-preflight
+requests include [:Access-Control-Request-Method:], which is [=forbidden
+request-headers|forbidden=]. Any headers that a fetch caller sets will not be set on a
+CORS-preflight request made by an honest user agent; instead, these are listed in
+[:Access-Control-Request-Headers:].
+
+
The [:Sec-Purpose:] field tells a server that a
+request 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
+forbidden request-header has no security-relevant purpose and the `Sec-` prefix
+is therefore unnecessary.
+
+
There are a number of headers that use the `Sec-` prefix for
+legacy reasons. Consistency with these existing headers is not a reason to use the
+`Sec-` prefix for new headers.
+
+
Client +hints give a server the ability to adapt content. Making these forbidden request-headers +denies fetch callers the ability to access this adaptation capability unnecessarily. + +
The `Sec-` prefix has no purpose for headers that are exclusively used
+for responses. Only consider the application of the `Sec-` prefix headers that are used in requests.
+
+
The [:Sec-WebSocket-Accept:] header is a
+response header that is exclusively used for the
+WebSocket handshake. This
+header has no need to use the `Sec-` prefix.
+
+
Thanks to