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

There are a lot of examples where the `Sec-` prefix is used without a lot of consideration for why.

This change is an attempt to articulate why you might want to use this prefix and deny a website the ability to set a value for a header.

Examples of `Sec-` that make the platform worse include `Sec-CH-` prefixed headers, which all engage server content negotiation capabilities that sites might be able to use.  I would include `Sec-Browsing-Topics` in this category also, but maybe for more reasons than one.

Examples that are mostly just pointless include `Sec-GPC` and `Sec-Purpose`, which both have no security-relevant decision that might be made by a server.

The `Sec-Fetch-Dest` and `Sec-Fetch-Mode` headers are good examples of things that would have security consequences if they weren't prefixed.  We also have a bunch that are forbidden and not prefixed that make a bunch of sense, like `Connection`.

I make an argument for `Sec-WebSocket-Key` in the text, which seems pretty solid to me. I can't make a similar argument for the other websocket headers.  `Sec-WebSocket-Accept` is a response-only header, so the prefix makes no sense other than for naming consistency, which is a bad reason.

Part of the reason for this is that we're seeing a bunch of cargo-culting in the definition of headers.  Take device-bound session credentials (https://github.com/w3c/webappsec-dbsc), which defines a response header called `Sec-Session-Registration`.  There, the reason appears to be consistency with request header naming, but it's not clear that the request headers themselves need a `Sec-` prefix either.

<!--
Thank you for contributing to the Fetch Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->

- [ ] At least two implementers are interested (and none opposed): n/a
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at: n/a
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed: n/a
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: n/a
- [x] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/fetch/1818.html" title="Last updated on Mar 31, 2025, 6:42 AM UTC (c8dcd84)">Preview</a> | <a href="https://whatpr.org/fetch/1818/5a96806...c8dcd84.html" title="Last updated on Mar 31, 2025, 6:42 AM UTC (c8dcd84)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1818

-- Commit Summary --

  * Add usage advice for Sec-

-- File Changes --

    M fetch.bs (100)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1818.patch
https://github.com/whatwg/fetch/pull/1818.diff

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

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