SameSite Cookie Attributes& Redirect Behavior
The SameSite attribute of the HTTP cookie has attracted the attention of web application developers. Currently in Google Chrome, the default value of the SameSite attribute of the new HTTP cookie is Lax.
https://www.chromium.org/updates/same-site
Aug 11, 2020: The target rollout population has been increased to 100% of users on Chrome Stable versions 80 and above, and the actual proportion of users with the new behavior enabled is now ramping up to 100% gradually. Users will receive the new behavior when they restart Chrome.
The specifications of the SameSite Cookie and the status of support for the respective UserAgent are listed below.
I have created a simple tool to check the SameSite attribute and behavior of HTTP cookies.
Elixir, Phoenix is used, but all it does is issue and display cookies.
First, let’s issue a cookie with various attributes.When you click on a link, six types of cookies are issued.
Google Chrome (84.0.4147.135) seems to ignore cookies with SameSite=None and Secure=false, but other browsers seem to behave differently.
Next, let’s look at the behavior of the cross-site request.There is a link and form on another domain.
https://ritou.bitbucket.io/dev/same_site_cookie_checker_helper.html
You can see that the GET request does not send SameSite=Strict cookies.
If you POST, you will see that SameSite=Lax cookies are not sent either.
In the world of OpenID Connect / OAuth 2.0, UserAgent does not send some HTTP cookies (SameSite=Lax/Strict) when making POST request in cross domain such as response_mode = form_post, form_post.jwt (JARM)
In addition, any extension specification that allows for front-end logout would be affected. Some specs that use “iframe” have references to ITP and the like, but we’ll see similar references to specs that use POST requests in the future.
Developers should use these tools to understand the behavior of the HTTP cookie while implementing it securely. Would you like to use this in your browser?