This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "SameSite"
Dirk Wetter (talk | contribs) (Add Safari, remark for IE11/Windows 7. Remove PHP section, see discussion.) |
|||
| (8 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | == Overview == | |
| + | |||
| + | SameSite prevents the browser from sending this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage. It also provides some protection against cross-site request forgery attacks. Possible values for the flag are <code>lax</code> or <code>strict</code>. | ||
| + | |||
| + | The <code>strict</code> 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 <code>strict</code> flag would be most appropriate here. | |
| − | + | The default <code>lax</code> 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. <code>POST</code>). | |
| − | + | As of November 2017 the SameSite attribute is implemented in Chrome, Firefox, and Opera. Since version 12.1 Safari also supports this. Windows 7 with IE 11 lacks support as of December 2018, see caniuse.com below. | |
== References == | == References == | ||
* https://tools.ietf.org/html/draft-west-first-party-cookies-07 | * https://tools.ietf.org/html/draft-west-first-party-cookies-07 | ||
| + | * https://caniuse.com/#search=samesite | ||
* http://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/ | * http://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/ | ||
| − | |||
Latest revision as of 13:03, 17 December 2018
Overview
SameSite prevents the browser from sending this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage. It also provides some protection against cross-site request forgery attacks. Possible values for the flag are lax or strict.
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).
As of November 2017 the SameSite attribute is implemented in Chrome, Firefox, and Opera. Since version 12.1 Safari also supports this. Windows 7 with IE 11 lacks support as of December 2018, see caniuse.com below.
