Use sec-fetch-site for socket transports

[josevalim]

The Sec-Fetch-Site header will allow us to validate the origin in a cleaner way. Also, because the clients to the transports are fewer, we can simply enforce the field to be set.

The question is which API we will want to be set. One option is to do check_origin: :sec_fetch_site, but since :sec_fetch_site itself has a few options, that's may become cumbersome. Another option is to introduce another keyword altogether. When this keyword is given, it disables check_origin and check_csrf (unless those are explicitly given).

[patric-vinicios]

What is supposed to happen if the header isn't there?

Absence is basically "non-browser". That's fine from a CSWSH perspective, but it's also how the clients the docs currently point at check_origin: false behave. So requiring the header would drop those clients in exchange for very little, since the guarantee it buys only ever applied to browsers anyway.

Are you planning to reject requests when the header is missing or fall back to the existing check_origin/check_csrf path?

On the API:

merging it into check_origin would introduce a sixth variant for that option, alongside true/false/list/:conn/MFA, while the values of Sec-Fetch-Site are somewhat orthogonal to it. Would it be better to come up with a separate keyword, similar to how check_csrf was added in #5952? What did you have in mind?

Worth noting that the WS handshake and longpoll are different request types here (longpoll is plain HTTP) so they may not behave the same.

[SteffenDE]

Absence is basically "non-browser"

Correct. The idea is to treat requests with the header missing as non-browser and allow them. I don’t think there’s a reason to reject.

[josevalim]

I'd say the opposite: we expect it to always be required, otherwise old browsers will be vulnerable. This is an OK requirement to make because 3rd party clients (iOS, Android, etc) can simply include the header too (it is a more controlled environment than regular requests).

[patric-vinicios]

that makes more sense. An old browser gives the same absence.

2 things I'm still unsure about:

• if native clients are supposed to send it, what value should they use? same-origin?
• does "always required" push this towards being opt-in? Turning it on would break any client that hasn't added the header yet which feels like an argument for a separate keyword rather than a new check_origin value

[josevalim]

if native clients are supposed to send it, what value should they use? same-origin?

same-origin or none.

does "always required" push this towards being opt-in?

Potentially. But given it is only a configuration change, a change of default to a more secure one is fine.