While implementing HTTP cookie SameSite flag for Django session cookies I also had to document it, which is always a good opportunity to create a brief but comprehensive description of the security control in general. As it will be surely used by security scanners in future, and SameSite can take two values, here’s a brief discussion of their usage scenarios.
The SameSite flag prevents a HTTP cookie from being sent in cross-site requests thus preventing CSRF attacks and making some methods of stealing session cookie impossible.
Possible values for the flag are lax or strict and this is where most web developers may have tough time understanding precisely what should be used when.
The strict value will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. For example, for a GitHub-like website this would mean that if a logged-in user follows a link to a private GitHub project posted on a corporate discussion forum or email, GitHub will not receive the session cookie and the user will not be able to access the project.
A bank website however most likely doesn’t want to allow any transactional pages to be linked from external sites so the strict flag would be most appropriate here.
The default lax value provides a reasonable balance between security and usability for websites that want to maintain user’s logged-in session after the user arrives from an external link. In the above GitHub scenario, the session cookie would be allowed when following a regular link from an external website while blocking it in CSRF-prone request methods (e.g. POST).
The upcoming SameSite support in Django is discussed here https://code.djangoproject.com/ticket/27863 and the patch is here https://github.com/django/django/pull/8380