Add Signature to CORS non-wildcard request-header name

[mnot]

What is the issue with the Fetch Standard?

RFC 9421 defines the Signature header field. One of its use cases is signing requests, effectively acting as a credential.

Because Fetch automatically follows redirects and copies headers from the original request into the redirect request, this means that a signature will be sent cross-origin, exposing its contents to a third party server.

One use case we have for this is authenticating bots (like web crawlers) to sites. If a site can be configured to redirect to another one, this would allow the third party site to impersonate the bot to the original target site.

Adding Signature to CORS non-wildcard request-header name would mitigate this.

/cc @jricher

[annevk]

@ricea @youennf @valenting @mozfreddyb thoughts? On the face of it this seems reasonable to me, but we need to make sure it's web compatible somehow.

[mnot]

Other option would be to allow the caller to append to the list of field names to block.

[mozfreddyb]

As @annevk says, it looks reasonable, but I am not aware of any usage of the Signature header at all. So take that with a pound of salt.

[jricher]

Note that you'd also want to add the Signature-Input header to the same list, as they're designed to work together in tandem.

RFC9421 is in use for API protection but I haven't seen it as much browser-side yet. I would personally love to see native support added to fetch() calls (ie, pass in a key and signature parameters and it signs the message with a non-exported key for you).