Sec- prefix for a server header

[yoavweiss]

AFAIK, the purpose of the Sec- prefixed header is to provide some guarantees about browser-provided headers and prevent JS code from altering/overriding them. I don't think any of that applies to server provided headers.
Is there any reason for the prefix?

[kmonsen]

@arnar Suggested this.

Headers go both way here, so there are are headers sent were we want this kind of protection. We also want this protection for response headers to make sure JS cannot alter them to protect from among others reply attacks.

[yoavweiss]

Headers go both way here, so there are are headers sent were we want this kind of protection.

That makes sense for the request headers, but I'm not convinced that the response headers should mirror that prefix.

We also want this protection for response headers to make sure JS cannot alter them to protect from among others reply attacks.

I don't think Sec- gives you that protection.

[theMiddleBlue]

https://datatracker.ietf.org/doc/html/rfc8942#:~:text=the%20Sec%2D%20prefix,%C2%B6

the Sec- prefix on the header field name has the effect of preventing scripts and other application content from setting them in user agents. Using the "Sec-" prefix signals to servers that the user agent -- and not application content -- generated the values. See [FETCH] for more information.

[yoavweiss]

That's true for request headers but not for response headers.

[arnar]

The Fetch spec indeed only uses "sec-" to mark headers as forbidden request headers, and the only forbidden response headers are Set-Cookie and Set-Cookie2.

Forbidden response headers are filtered from JS to see them, based on a set of rules that e.g. include taking CORS into account.

So @yoavweiss is correct in that "Sec-" does not do anything automatically for response headers, but the takeaway is whether we should think about if any of the response headers we are defined ought to be forbidden headers (e.g. hidden from XHR responses).