SameSite (also known as first-party-only HTTP cookies) were introduced to counter Cross-SIte Request Forgery (CSRF) and other web attacks based on the automatic behavior of web browsers sending HTTP cookies to domains they are intended for, regardless of where the request is originating from.

By default, when user clicks on a link to on any third-party page (e.g. search engine results), the browser will send any cookies set for along with that request. This automation enabled attacks such as cross-site request forgery (XSRF) so in 2016 a new scope-limiting option was introduced called SameSite. Cookies set with this option will be only sent by the browser with requests within the same website — so only for an internal link from leading to

The option comes in two flavors that determine precise behavior of the browser on cross-site requests — SameSite=Strict will enforce a more restrictive approach, outlined above. While more secure, it has also an adverse effect on website usability and user experience — for example, logged-in users of eBay who clicked through a product page from a search engine would see their session as logged out because this constitutes a cross-site request and their authentication cookie will not be sent (if eBay used SameSite cookie, that is).

Because of this, the Strict mode is intended on high-security websites that are never intended to be linked from third-party pages (e.g. bank transactional pages). A more relaxed policy SameSite=Lax is a compromise between usability and security — it will allow "safe" cross-site requests to be sent with the cookie (e.g. simple requests to view pages), while preventing "state changing" requests that might have side effects (e.g. a request that would result in placing a bid on eBay).

The option was added in Chrome 51 and Opera 39 in 2016.

A sample HTTP cookie using the flag might look like this:

Set-Cookie: name=value; SameSite=Lax

The SameSite flag is defined in an Internet Draft draft-ietf-httpbis-cookie-same-site-007.