Should we ignore invalid values?

[sspi]

For each header the spec says: "In order to support forward-compatibility with as-yet-unknown request types, servers SHOULD ignore this header if it contains an invalid value."

I think it is really dangerous: when developers adopt this standard they will use it as a real security feature, because, as the spec says, CSRF is really difficult to solve without this spec.
Now imagine that a new spec version adds a different value: all deployed servers that implement the old specification will offer a security hole or be unusable (depending on how developers check the values as black list or white list).

Proposal:

• For at least the most important header, Sec-Fetch-Site (and probably others), a new spec version will never add a different value BUT could sub-divide a value in a more specific category with a suffix. Example: cross-site/case-1, cross-site/case-2.
• Developers SHOULD always evaluate the value with a startsWith() function.

[arturjanc]

I think this is a reasonable approach, and IMHO the spec may be a little too defensive when it comes to avoiding breakage due to unknown values.

My guess is that at least for Sec-Fetch-Site it is quite unlikely that there will be additional values, and the logic I'd expect servers to use will not be sensitive to new values (e.g. blocking site != 'same-origin' or site == 'cross-site'). If we come to that, an alternative solution which will not require developers to do substring matching is to introduce a new Sec-Fetch value to differentiate between the options; say, Sec-Fetch-Site: cross-site + Sec-Fetch-First-Party-Set: ?1.

I'm not sure if there's much to do here other than possibly softening the wording, but we should keep this in mind if/when we consider adding new values to site or mode.

[sspi]

for Sec-Fetch-Site it is quite unlikely that there will be additional values

I have some doubts. I don't want to launch the topic here (for this version of the spec), but other values that would find interesting use cases would be something like cross-site/same-root-domain-2 and cross-site/same-root-domain-3, ie a request which comes from the same 2 (domain.com) or 3 (domain.co.uk) root domain parts.

[mikewest]

I'm going to close this out, as I think it's something to consider only if/when we add new values to existing headers. At the moment, that doesn't look terribly likely for Sec-Fetch-Site, and the additions we're thinking about take the form of new headers (e.g. #56).