If the SameSite attribute is set to Strict, then the browser will not include the cookie in any requests that originate from another site
. This is the most defensive option, but it can impair the user experience
, because if a logged-in user follows a third-party link to a site, then they will appear not to be logged in, and will need to log in again before interacting with the site in the normal way.
If the SameSite attribute is set to Lax, then the browser will include the cookie in requests that originate from another site but only if two conditions are met:
- The request uses the GET method. Requests with other methods, such as POST, will not include the cookie.
- Imagine we have a very bad design and all our actions are performed on GET method. The attacker placed link saying "Save puppies" which links to
http://oursite.com/users/2981/delete
- Imagine we have a very bad design and all our actions are performed on GET method. The attacker placed link saying "Save puppies" which links to
- The request resulted from a top-level navigation by the user, such as clicking a link. Other requests, such as those initiated by scripts, will not include the cookie.
Using SameSite cookies in Lax mode does then provide a partial defense against CSRF attacks, because user actions that are targets for CSRF attacks are often implemented using the POST method. Two important caveats here are:
- Some applications do implement sensitive actions using GET requests.
- Many applications and frameworks are tolerant of different HTTP methods. In this situation, even if the application itself employs the POST method by design, it will in fact accept requests that are switched to use the GET method.
Obviously, these limited benefits come at a serious UX tradeoff, and so are typically not worth it compared to the already-pretty-good protections offered by samesite=lax
.
For the reasons described, it is not recommended to rely solely on SameSite cookies as a defense against CSRF attacks. Used in conjunction with CSRF tokens
.
We use a redirect page to break the chain of requests from external websites that allow the browser to send a login cookie.
- First access
http://localhost:8080/cookie
and this will set a cookie namedaccess-token
whichSameSite
isStrict
. - When user access
http://localhost:8080/success
from external website. - Then browser will redirect to
http://localhost:8080/success
with status code is307
but withoutaccess-token
cookie. - Then browser will redirect to
http://localhost:8080/redirect
which status code is200
but withoutaccess-token
cookie. - Finally browser will redirect to
http://localhost:8080/success
which status code is200
but withaccess-token
cookie.