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

martinthomson left a comment (whatwg/fetch#1818)

@annevk I find your claim about SOP confusing.  This has very little to do with SOP or the security model.  I'm not looking to change the definition of `Sec-`: there are clear examples of where it is valuable.  I'm just seeking to establish clear rationale by which someone might choose to apply it that don't involve reasoning of the form "just in case".

@johannhof The pull request makes the case pretty clearly already.  Maybe you disagree.  The problem is that denying script the option to request content with forbidden fields forces the use of alternative spellings of the exact same semantics.  Consider Sec-CH-DPR.  Is there any security reason why a site should not be permitted to request content with a higher DPR than the screen on which the browser assumes it might be displayed?

I don't know that a threat model has been documented, but I don't think that the one you both seem to have settled on is useful.  If we consider preflight to be effective in blunting the effectiveness of attacks, and that preflight is included whenever a non-safelisted field is added to a request (at least when using the API; by the way, there is a reason that people always end up asking @annevk to interpret this specification, I had a really hard time working this out; I'm still not confident that I've 100% covered that).  There are then no cases where an "attacker"-controlled request appears without first getting permission from the resource.

More fundamentally, if new fields cannot be sent to servers, we have a major problem.  New fields are defined all the time.  There can be good reasons for browsers to send them.  They will appear in form submissions.  There's a good reason that the list of forbidden fields includes old fields, because those are more likely to be acted upon by servers that are not aware of CORS.  But for new fields defined so long after CORS became ubiquitous, it's silly to insist that a server might act on it in a way that can be exploited.

The threat model I documented is - at least in my view - a clearer one.  That is, if a server needs to make a security-relevant decision with confidence that the value of the `Sec-`-prefixed field came from the same place that the credentials did, then it is a good use of a forbidden header.

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

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