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).

[annevk]

Any progress on this?

I agree with OP that using Sec- for response headers is wrong. Presumably since these are new requests CORS is used and therefore the server could only expose these headers using Access-Control-Expose-Headers. I don't think we need a new mechanism that protects headers from being revealed even when included therein, but I guess I'm willing to be convinced. (If you manage to convince me though, Sec- seems like an inappropriate mechanism still as Sec- does not imply the header is not exposed. They sometimes are to service workers and such. It just means the header cannot be controlled.)

[arnar]

I have no strong opinion here, we put it in originally from a misunderstanding I think has been corrected in this discussion.

@kristianmonsen I'm fine dropping "Sec-" from the response headers.

[kmonsen]

I can change that, it's a bit of work so just checking here first if we agree on what would be better. My proposal is:

• All request headers stay as they are, so for example Sec-Session-Id and Sec-Session-Response. I'll try to think of a new name for Sec-Session-Response as it is a bit confusing.
• For all response headers, I'll change them from Sec-Session-* to Secure-Session-*, so for example Sec-Session-Registration becomes Secure-Session-Registration

Would this work?

[arnar]

The prefix "Sec-" was really serving two purposes, so that our headers aren't just "Session-..." -- since that term in isolation is already heavily overloaded.

I know it sounds silly but I think we should have a common prefix for all the headers defined by this spec, and since "Sec-Session-" doesn't work, the next best option is "Secure-Session-" everywhere. That means the request headers would be "Sec-Secure-Session-..." 🙄

But silly as it is, that's IMO better than sometimes using "Secure-Session-" and other times "Sec-Session-". And it assigns no additional meaning to "Sec-", which is what I understand this issue to be about.

[kmonsen]

So:

• Request: Sec-Secure-Session-*
• Response: Secure-Session-*
  ?

My preference would be to make them all Secure-Session-*, I am not sure if Sec- on request headers really changes anything practically for DBSC..

[annevk]

I think if it's exactly the same header using the same name is reasonable.

Where in the Fetch processing model do these get set? What if a web developer has already set them? The former is important regardless, the latter is important if you don't use Sec-.