As of February 2020, Chrome 80 started a staged rollout of "SameSite" restrictions on cookies. Other browser have since followed suit. And by default, cookies with an undefined "SameSite" attribute have been treated as "Lax".
However, it appears that more recent changes to browsers are treating them as being set to "None", resulting in the below error for the app's session cookie:
This PR defines the "SameSite" attribute and also updates a few other security attributes: HTTP Only, Secure, and Expiration.
Considerations
While the lowest risk of a breaking change would have been to set cookies to same_site: :none, secure: :true, this is also the least secure option as it allows unrestricted third party access to the session cookie so long as it is through an HTTPS connection.
Alternatively, I could have also defined the session cookie assame_site: :lax. In SameSite cookies explained, this seems like a great option if there were some kind of promotional add from a third party site, which add the promotion to the user's state.
In this case, I really only use the cookie for logging the user in. So, it seems like the most secure option same_site: :strict is the right approach. There is no context in which I would ever need access to the session cookie outside of first-party requests.
Summary
As of February 2020, Chrome 80 started a staged rollout of "SameSite" restrictions on cookies. Other browser have since followed suit. And by default, cookies with an undefined "SameSite" attribute have been treated as "Lax".
However, it appears that more recent changes to browsers are treating them as being set to "None", resulting in the below error for the app's session cookie:
This PR defines the "SameSite" attribute and also updates a few other security attributes: HTTP Only, Secure, and Expiration.
Considerations
While the lowest risk of a breaking change would have been to set cookies to
same_site: :none, secure: :true, this is also the least secure option as it allows unrestricted third party access to the session cookie so long as it is through an HTTPS connection.Alternatively, I could have also defined the session cookie as
same_site: :lax. In SameSite cookies explained, this seems like a great option if there were some kind of promotional add from a third party site, which add the promotion to the user's state.In this case, I really only use the cookie for logging the user in. So, it seems like the most secure option
same_site: :strictis the right approach. There is no context in which I would ever need access to the session cookie outside of first-party requests.Notes
For more information about SameSite best practices, check out Cookie recipes - SameSite and beyond.