About
samesite is a cookie property that controls if a cookie should be sent along in a cross-site HTTP request ie:
- when the origin of the code (HTML, Javascript, ..) that created the request (generally the HTML page itself)
- is not the same than the origin of the request (based on the URL)
The browser reads this value when doing a browser request (fetch) and determines if it should add to the request:
- the first-party cookies (known also as same-site cookie)
- and/or third party cookies
Example and confusion
Consider the scenario in which a user:
- reads their email at “https://mail.third.com/”.
- click an emailed link to a protected page on another website: “https://first.com/protected/project”
If intranet.com has marked the session cookie with the samesite value as:
-
- The browser won't add the session cookie to this cross-site request
- first.com will respond with a 401 error (Non authorized).
- The user is confused because they are authorized to see this project and they were already logged in
-
- The browser will add the session cookie to this cross-site request
How to avoid the confusion?
Developers can avoid this confusion by adopting a session management system that relies on not one, but two cookies 1):
Number | Cookie Authorization | SameSite | Description |
---|---|---|---|
1 | read | Lax (or empty) | Allow users access to data via top-level navigation |
2 | write | Strict | Disallow write operation via top-level navigation |
The absence of the second cookie would provide a reauthentication step before executing any non-idempotent action.
Usage / Use Case
Appropriate
When a cookie is a same-site cookie (ie with the strict or lax value), this parameter allows a robust defense against:
- and information leakage attacks
InAppropriate
The strict or lax value are inappropriate for:
- content embedding in a cross-site contexts (social networking widgets or commenting services, for instance) where the user's state is needed
- Single-Sign-On that require authentication in a cross-site context
Values
SameSite values
Lax
Lax is the Default in browser
Cookies:
- are allowed to be sent with top-level navigations (when this is the first navigation)
- will be sent along with safe request (request method that does not changes state such as GET, HEAD) initiated by a third-party website.
- are prohibited for an unsafe request method (ie request method that changes state such as POST, PATCH, PUT).
In other words, first-party cookies:
- are not sent on cross-site sub-requests, such as calls to load images or frames,
- are sent when a user navigates to the URL from an external site (third-party website), for example, by following a link.
Strict
In Strict mode, cookies
- are not added for any kind of cross-site request. (They will not be added along with requests initiated by third-party websites).
- are only be sent in a first-party context (same-site)
The browser will only send cookies for same-site requests (requests originating from the site that set the cookie).
- If the request originated from a different URL than the URL of the current location, none of the cookies tagged
- with the Strict attribute will be included.
None
In None mode, Cookies will be sent in all contexts, i.e sending cross-origin is allowed (ie third party cookie are added)
In this mode, the security flag should be set (ie HTTPS is mandatory)
For development purposes, you can disable the security requirement with a option flag.
Glossary
Same-site cookie
A same-site cookie is a cookie where the same-site value has been set to strict or lax
Top-level site
The “top-level site” is the registered/apex domain in the address bar of the browser.
Same-site vs Cross-site
A request is:
- same-site if its target's URI's origin's registrable domain is an exact match for the request's initiator's (the parent),
- and cross-site otherwise.
Example:
- login.example.com and blog.example.com will trigger same-site request because they share the same apex domain.