Understanding HTTP cookie SameSite flag usage scenarios


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