Skip to main content Link Search Menu Expand Document (external link)
SameSite Wiki

SameSite Wiki

Stable

This wiki is meant to introduce readers to the SameSite cookie policy and also serve as a reference guide for experienced researchers and developers using SameSite cookies.

Contribute Now View it on GitHub

Overview

SameSite policies defines the request contexts in which browsers include cookies in HTTP requests, such as same-site and cross-site requests. Using SameSite policies, developers can limit the scope of session cookies to a first-party context to protect their web applications from two important families of cross-site (XS) web attacks, that is, Cross-Site Leaks (XS-Leaks) and Cross-Site Request Forgery (CSRF), by stripping authentication cookies from cross-site requests the user nor the web application intended to initiate.

Over the past many years, researchers and practitioners have come up with different solutions to enforce SameSite policies, such as proxies[1, 2, 3], browser extentions[4, 5, 6], or a combination of them[7]. Unfortunately, these solutions require installing additional components, limiting their impact considerably.

In 2016, Google revamped the idea of SameSite policies by proposing and implementing in Chrome a new cookie attribute[8], the SameSite attribute of the Set-Cookie HTTP response header, which was proposed as a part of the RFC 6265bis specification[9]. Today, the SameSite cookie attribute is supported by most major browser vendors (see, i.e., here), acting as an important defense-in-depth against XS attacks.

XS Attacks

XS attacks are a family of web attacks where attackers lure users into visiting a malicious web page that tricks the user’s web browser to send authenticated cross-site HTTP requests to a vulnerable target website. One of the first instances of cross-site attacks is Cross-Site Request Forgery (CSRF), where attackers leverage cross-site requests to perform security-sensitive, server-side state-changing operations, such as user credential reset or money transfers, without user’s consent or awareness.

Malicious cross-site requests can also target the users making these requests by leaking sensitive information about user’s login status[12, 13], account type[10], age range[14], or user’s identity[10, 11]. These attacks are often called cross-site information leakage (XS-Leaks) or Cross-Origin State Inference (COSI) attacks[10].

CSRF and COSI attacks have a similar two-phases attack pattern: preparation and attack. In the preparation step, the attacker prepares a malicious webpage referring to resources from the target site. These can be, for example, a hidden, self-submitting HTML form to reset the user password at the target site or a JavaScript file hosted by the target site. During the attack phase, the user is lured into visiting the attack page. As a result of the included resource, the user’s browser sends a cross-site request to the target website, and the browser automatically attaches the user’s authenticated session cookies to this request. The target website receives and processes the request. In the case of CSRF, the server will perform the requested operation, e.g., by resetting the user password with an attacker-controlled one. In case of a COSI attack, the attack page uses browser side-channels to leak sensitive information about the user. For example, consider a cross-origin HTTP request that returns a 200 response code when the user is logged in and a 404 otherwise.

A Little Bit of History

The main benefit of the SameSite attribute is a more stricter default cookie policy, which can disrupt existing websites. To help developers transition to the new default policy, Google introduced three gradual changes to Chrome, introduced in 2016, 2019, and 2020.

In April 2016, Chrome 51 introduced support for the new SameSite cookie attribute[8] without modifying the default policy. Later, in September 2019, Chrome 77 started showing console warning messages for cookies missing the SameSite flag. The final step of this transition took place in 2020, with Chrome 80. First, in February 2020, Chrome set Lax+POST the new default policy. However, shortly after, Google rolled it back (April 2020) to ease developers’ transition to the new policy in light of the COVID-19 pandemic. The Lax-by-default was then restored in July 2020 with Chrome 84.

About This Wiki

While the wiki covers different aspects of SameSite policies, new security risks and threats are always emerging. Improvements and suggestions, whether to add new content or expand existing documentation, are always more than appreciated. For more information, please refer to contribution guidelines.

References

  1. Alexei Czeskis, Alexander Moshchuk, Tadayoshi Kohno, and Helen J. Wang, Lightweight server support for browser-based CSRF protection. In Proceedings of the International Conference on World Wide Web, 2013. Link.

  2. Florian Kerschbaum, Simple cross-site attack prevention. In 3rd International Conference on Security and Privacy in Communication Networks and the Workshops (SecureComm 2007). IEEE, 464–472. Link

  3. Martin Johns and Justus Winter, RequestRodeo: Client side protection against session riding, 2006. Link

  4. Ziqing Mao, Ninghui Li, and Ian Molloy, Defeating Cross-Site Request Forgery Attacks with Browser-Enforced Authenticity Protection (BEAP). In 13th International Conference on Financial Cryptography and Data Security, 2009. Link

  5. Philippe De Ryck, Lieven Desmet, Thomas Heyman, Frank Piessens, and Wouter Joosen, CsFire: Transparent Client-Side Mitigation of Malicious CrossDomain Requests. In ESSoS, 2010. Link

  6. Philippe De Ryck, Lieven Desmet, Wouter Joosen, and Frank Piessens, Automatic and Precise Client-Side Protection against CSRF Attacks. In ESORICS, 2011. Link

  7. Sebastian Lekies, Walter Tighzert, and Martin Johns, Towards stateless, client-side driven Cross-site request forgery protection for Web applications. SAP Research, 2012. Link

  8. Mike West, Same-site Cookies, 2016. Link

  9. Cookies: HTTP State Management Mechanism, 2020. Link

  10. A. Sudhodanan, S. Khodayari, and J. Caballero, Cross-Origin State Inference (COSI) Attacks: Leaking Web Site States through XSLeaks, in NDSS 2020. Link

  11. C. A. Staicu and M. Pradel, Leaky Images: Targeted Privacy Attacks in the Web, in USENIX Security Symposium, 2019. Link

  12. Mike Cardwell, Abusing HTTP Status Codes to Expose Private Information, 2011. Link

  13. Yoneuchi, Takashi, Detect the Same-Origin Redirection with a bug in Firefox’s CSP Implementation, 2018. Link

  14. T. Van Goethem, W. Joosen, and N. Nikiforakis, The Clock is Still Ticking: Timing Attacks in the Modern Web. In CCS, 2015. Link