Samesite cookie - Strict & Lax
At the beginning, it is worth mentioning that the http protocol is stateless, which means that the server will treat any query from one browser as new. Cookies that create a session management mechanism come to the rescue here. The server, using the Set-Cookie header, tells the browser to save the cookie in its memory. Then it will be automatically included when queries to the specified domain are made.
However, the problem arises when you need to distinguish who actually triggered the request to a specific resource - the user by clicking the appropriate button or the script that did it automatically. Such behavior leads to a CSRF (Cross-Site Request Forgery) vulnerability.
A way to limit this behavior of browsers is to set the SameSite flag. It can take two values - Strict and Lax.
First we'll deal with Strict. Assigning this value to the flag will cause the browser to not attach it to the request when the query is sent from a domain other than the one for which the cookie was created. However, using this solution can be quite a hassle as you will be required to enter your credentials each time a user wants to click on a link to resources in a different domain.
In the case of Lax, the decision to submit the request is made on the basis of two things. The first is top-level-navigation, that is, changing the url. This is important because it is the only source of information a user can notice the change and find out in what domain context the query is being made. Another thing is to use the secure http method (GET, HEAD, OPTIONS, TRACE). The term 'safe' should be interpreted as one, the execution of which does not change the state of the application. If these two conditions are met, the cookie will be sent.
Finally, it is worth adding that even in the case of using SameSite, our application may be vulnerable to attacks. This is the case when we allow the application state to be changed using the secure http method. This is obviously inappropriate practice. Another fact is that the flag in question allows for the implementation of client-side security, which should be considered additional. This means that the security mechanisms on the server side should not be abandoned.