Standardizing Security Semantics of Cross-Site Cookies

1. Introduction

Major browsers have shipped or announced plans to restrict cookies in cross-site contexts to improve the privacy of their users and protect them from cross-site tracking. [W3C-PRIVACY] However, the details of which requests are considered cross-site vary between browsers; as a result, browsers' cookie blocking behaviors have subtle differences. Because of the importance of cookies to the web platform, and the substantial amount of existing web content and functionality that depends on the presence of cookies in cross-site contexts, it is important to converge on interoperable cookie semantics that uphold the platform’s security and privacy guarantees.

However, to make informed decisions that help browser vendors converge on consistent cookie semantics, it seems necessary to review the privacy and security goals of third-party cookie blocking. Specifically, we need to evaluate how the presence of cookies in cross-site contexts results in a number of endemic web vulnerabilities, undermining the security of existing web applications and requiring costly application-level mitigations in all sensitive web services. This analysis helps guide our decisions about where cookies may be safely allowed in cross-site contexts, and where browsers need to block them to enforce a robust security boundary for web content.

The goal of this document is to promote interoperability and specify cross-site cookie blocking semantics for cases where browser behavior diverges, while maintaining the privacy and security properties of cross-site cookie blocking.

1.1. Summary

This proposal aims to:

1. Develop a shared understanding of cross-site cookie blocking and its potential security benefits for browser implementers, specification authors, and web developers.

2. Support these security benefits and specify common rules and semantics for cross-site cookie blocking, for future standardization in HTML, Fetch and the Cookies RFC.

3. Discuss how new web features such as the Storage Access API, Cookies Having Independent Partitioned State (CHIPS), and related mechanisms might interact with cross-site cookie blocking to restore access to blocked SameSite=None cookies if needed, while upholding the privacy and security principles of cross-site cookie blocking. [STORAGE-ACCESS-API] [CHIPS]

1.2. Security Concerns With Attaching Cookies On Cross-Site Requests

Cookies have traditionally followed the ambient authority security model: once a cookie has been set for a given scope (generally, a domain and path), it would be attached on all requests to that scope regardless of the sender of the request. [CORS-FOR-DEVELOPERS] A consequence of this behavior is that unrelated websites can forge credentialed requests to any application to which a user is logged in; these requests, authenticated with the user’s "first-party" credentials carried in a cookie will be virtually indistinguishable to the destination web server from requests generated in a first-party context. Unless the server takes additional steps to review the provenance of the request and reject it if it was sent by an untrusted sender, an attacker-controlled request may be able to interact with the destination server as if it had been issued by the application itself.

Because endpoints on the web are all identified in a common format, the URL, a malicious site will know the address to which to send a request in order to interact with chosen server-side functionality and issue a request with the user’s cookies. This makes the web unsafe by default and requires applications to implement defenses to protect themselves from cross-origin attacks. Applications that fail to do so are commonly vulnerable to well-known, endemic classes of isolation vulnerabilities. This includes:

• Cross-site request forgery [CSRF], allowing triggering arbitrary state-changing actions on the user’s behalf.

• Clickjacking [CLICKJACKING], tricking the user to click on a UI element to trigger an unwanted action.

• Cross-site script inclusion [XSS], leaking authenticated data from responses parseable as JavaScript.

• Cross-site leaks [XS-LEAKS], including XS-Search and various web-level timing attacks, revealing application-specific data belonging to the logged in user.

  • As a special case, the exploitation of Spectre against web resources also relies on the attacker loading an eligible authenticated resource into an attacker-controlled renderer process and reading it from memory using hardware-level vulnerabilities. [POST-SPECTRE-WEB-DEVELOPMENT] [HARDWARE-LEVEL-VULNERABILITIES]

In addition to these widely recognized web application vulnerability classes, the sending of authenticated cross-site requests has also been demonstrated to introduce other security and privacy risks, such as:

• Login status detection [XSHM], permitting an attacker to learn whether the user is currently logged into a chosen website.

• Targeted deanonymization [TARGETED-DEANONYMIZATION], to determine if the user is logged into a specific account on a target website.

• Login CSRF [LOGIN-CSRF], allowing the attacker to log the user into an attacker-controlled account.

• Logout CSRF [LOGOUT-CSRF], to end a user’s session in an unrelated web application.

Put simply, the traditional behavior of cookies has consistently posed substantial security problems for web applications and significantly impacted the security and privacy properties of the web platform.

1.3. Gaps in Third-Party Cookie Blocking

In recent years some web browsers have responded to cross-site tracking concerns by employing various restrictions to remove cookies on cross-site subresource requests. This included blocking the sending of cookies based on a domain-level denylist (either global or built locally on-device) and, ultimately, blocking all cookies from third-party contexts. [FULL-THIRD-PARTY-COOKIE-BLOCKING]

However, these approaches do not fully align their definition of a third-party (or cross-site) cookie with the web’s security model. The main difference is that privacy-motivated blocking of third-party cookies only disables cookies on requests that are cross-site relative to the top-level document. This approach to cookie blocking permits cookies for requests that are same-site relative to the top-level window, even if these requests were made by cross-site frames.

This results in a situation where the presence of any cross-site frame under a given site allows entities that control content in that frame to exploit cross-site vulnerabilities anywhere under the embedding site. Cross-site embedding is common on the web: major use cases of cross-site iframes include advertising, conversion tracking, and widgets such as embedded videos, maps, or social commenting. This exposes a large number of websites to risks associated with authenticated cross-site requests.

Third-party cookie blocking also allows attaching cookies to cross-site top-level navigation requests, including those using unsafe HTTP methods (e.g. POST). While permitting this is required to maintain important use cases on the web, this behavior allows exploiting CSRF vulnerabilities through top-level form submissions using the HTTP POST method. This is discussed more in detail in Cross-site Interaction Scenarios below.

2. How Should Cookies Behave?

2.1. Existing cookie models

Over time, the web has accumulated a number of features that limit the situations in which a cookie can be attached to a cross-site request, including opt-in protections using the the SameSite Attribute, and default restrictions enabled in several web browsers. In this section we briefly cover these behaviors and propose a model which maintains both the security and privacy properties we want to uphold on the web.

2.2. SameSite=Strict

The SameSite=Strict cookie attribute prevents the cookie from being attached on any request that wasn’t issued by the same site as its destination. This robustly protects websites from cookie-based cross-site attacks because a malicious website isn’t able to issue any credentialed requests to a cross-site destination.

However, this behavior significantly changes some long-established cookie behaviors on which many web services have come to depend. For example, by blocking cookies on top-level navigations it results in any cross-site navigation to be treated as unauthenticated, even if the user is logged into the destination site. This limits the utility of SameSite=Strict cookies and has led to low adoption of this protection across the web.

2.3. SameSite=Lax

The SameSite=Lax attribute prevents cookies from being attached on cross-site resource requests (such as frames or images), but allows the cookie to be sent on top-level navigations using safe HTTP methods, such as GET.

This protects cross-site resources from being embedded with cookies and protects web services from most CSRF vulnerabilities (due to restricting cross-site POST requests). However, by allowing GET-based navigations, it permits websites to retain authentication after cross-site navigations, improving compatibility with existing web content.

2.4. SameSite=Lax with Compatibility Exceptions

In an effort to roll out protections based on SameSite=Lax cookies by default to the web, Google Chrome has implemented a cookie mode based on SameSite=Lax behavior, but with two additional relaxations:

• Lax-allowing-unsafe: Allow top-level cross-site navigations using unsafe methods (in practice, POST) to carry a cookie if the cookie had been created recently (specifically, if the cookie age is 2 minutes or less). [SAFE-HTTP-METHODS] This change was made because a number of common payment flows rely on top-level POST navigations and depend on the presence of cookies.

• Re-attaching credentials after cross-site to same-site redirects: Some websites contain resources and iframes pointing to cross-site destinations which then redirect back to an endpoint within the top-level site. The SameSite=Lax behavior is to remove cookies on the same-site redirect, which results in load failures for resources which require authentication; this relaxation was made to prevent websites depending on this pattern from breaking. [COOKIE-SAMESITE-BUG]

Both of these exceptions were made as a compromise between security and compatibility, in the interest of switching to safer default cookie semantics based on the SameSite=Lax model, without affecting legitimate, commonly used patterns.

2.5. Third-Party Cookie Blocking

The most common implementation of third-party cookie blocking restricts requests from carrying cookies if they are cross-site relative to the top-level window. However, it permits requests to destinations same-site with the top-level window to carry cookies, even if these requests were sent by cross-site iframes. This permits cross-site iframes to issue credentialed requests to the site of their top-level embedder, allowing them to exploit cross-site vulnerabilities.

2.6. SameSite=None

As part of the SameSite=Lax-by-default rollout, Google Chrome made it possible for developers to disable SameSite restrictions on cookies and permit these cookies to be sent on cross-site requests. [SAMESITE-COOKIES-EXPLAINED] This behavior, made possible by setting cookies as SameSite=None, is generally incompatible with the web’s privacy model because it allows the creation of third-party cookies that retain state across top-level contexts. Similarly, the current behavior of SameSite=None cookies isn’t aligned with the desired cookie security model because it removes all cookie-level protections against cross-site attacks. To re-align with the desired security model, the behavior of these cookies needs to change as part of privacy efforts.

SameSite=None cookies do have an important role to play on the web – they are necessary to allow developers to relax SameSite restrictions on cookies in places where such relaxations are compatible with the web’s security and privacy goals. We provide a detailed discussion of these scenarios in the Cross-Site Interaction Scenarios section below.

2.7. Overview

We believe that a successful cookie model needs to balance security and privacy with web compatibility. For example, given that many websites rely on receiving credentials when they’re navigated to from a cross-site destination, we couldn’t require the web to switch to SameSite=Strict cookies, as that would remove authentication after such navigations. This would favor security at the expense of compatibility and usability, and would arguably be detrimental to the web platform.

Similarly, the third-party cookie blocking approach can be seen as prioritizing compatibility over security. While it upholds privacy protections against cross-site tracking, it isn’t a robust security boundary because it allows cross-site attacks from embedded content. Under the web’s principle of composability it must be possible for websites to safely embed cross-site content without exposing themselves to attacks; as such, we believe that current third-party blocking implementations are insufficient from a security perspective.

Thus, the approach we should aim for falls somewhere between the SameSite=Lax and SameSite=Lax with exceptions behaviors, as discussed below.

2.8. End State Security Properties

In addition to the privacy goals of preventing cross-site tracking, from a security perspective, there are two core restrictions that the web platform needs to enforce on all cookies:

1. It should be impossible to make credentialed cross-site subresource requests (e.g. to load an image or iframe), unless the destination endpoint explicitly opts into being loaded with credentials in a cross-site context (for example, through calling requestStorageAccess or using Storage Access API headers. [STORAGE-ACCESS-HEADERS]

2. It should be impossible to make credentialed cross-site requests with unsafe methods, such as POST. Practically, this means that authenticated top-level navigations should only be allowed through GET requests.

Why can’t we allow developers to opt out of platform-level cookie security/privacy restrictions?

An important question is why the web platform should prevent developers from relaxing the security and privacy properties of cookies if they intentionally wish to do so.

From a privacy perspective, the answer is straightforward: the use of cookies in third-party contexts allows the creation of identifiers shared across top-level sites that can be used to track the user’s cross-site activity. The web platform aims to prevent this from happening.

From a security perspective, the chief concern is that relaxing a site’s cookie properties is likely to expose the site to cross-site vulnerabilities in ways that are difficult for developers to understand, especially in a world where cookie restrictions apply by default. This is problematic because of a combination of the following factors:

• Cookies are a coarse-grained mechanism: It’s common for a single authentication cookie to be used for a whole origin, or even site through the use of domain-wide cookies. [USING-HTTP-COOKIES] If a developer relaxes cookie protections to allow receiving credentialed cross-site requests to a single endpoint on their origin, they will expose their entire origin to cross-site attacks.

• Developers frequently need to allow credentialed cross-site interactions to at least a small number of endpoints. For example, an application may provide an authenticated iframe, CORS API, or resource embeddable by a small number of partner sites, or permit A>B>A-style embedding scenarios. If any single such pattern requires relaxing cookie security properties, it will be common for developers to broadly opt out of default platform cookie protections, unnecessarily reducing the security of their applications.

Because the main mechanism to relax cookie restrictions is to set them as SameSite=None, we thus need to make sure that the security properties of SameSite=None cookies are sufficiently robust. That is, we aim to make the "least safe" cookie behavior that developers can opt into when creating a cookie (by using SameSite=None) to still be safe enough to offer robust default protections.

Note: Developers will be able to relax cookie restrictions through the use of Storage Access API’s requestStorageAccess or Storage Access API headers. [STORAGE-ACCESS-HEADERS] However, these mechanisms are more tightly scoped and apply only at the level of individual documents or endpoints, reducing the risk of misconfiguring applications to make them broadly susceptible to cross-site attacks.

3. Cross-Site Interaction Scenarios

As outlined in the previous section, in general we aim to not attach unpartitioned cookies to cross-site requests, except for top-level navigations using safe HTTP methods, such as GET.

However, there are a number of cases where the relationship between the source and destination of the request is less clear, where current browser behaviors diverge. We outline these cases below, along with the recommended behaviors that meet the security and privacy goals.

3.1. Same-Site Embeds with Cross-Site Ancestors (A>B>A embeds)

Sites will have embeds that are same-site with the top-level site, but the embed has at least one cross-site ancestor in the frame tree. For brevity, we call these embeds A>B>A embeds.

When current third-party cookie blocking controls are enabled, major browsers' behaviors differ:

• Chrome will always block cookies in the A>B>A embed.

• Firefox allows the A>B>A embed to read cookies set by A as the top-level site, but the A>B>A embed cannot write new cookies.

• Safari and Brave allow A>B>A embeds to read and write cookies, including with headers in subresource requests to A that originate from an embedded site B frame.

3.1.1. Security Considerations

Allowing embeds with cross-site ancestors to have access to cookies has the consequence of also permitting any embedded site to make credentialed requests to the top-level domain. This could allow malicious third-party sites to exploit cross-site information leaks. [XS-LEAKS] The cookie specification requires that sites opt-in to cookies that need to be sent on cross-site requests with the SameSite=None attribute. One may contend that this already offers websites some protection by default. However, sites which enable SameSite=None cookies tend to have multiple endpoints, only some of which expect to be served in specific, trusted cross-site contexts. Endpoints which don’t expect cross-site interactions (and hence do not deploy sufficient protections against cross-site leaks or cross-site request forgery) might be unwittingly exposed to attacks from cross-site iframes.

3.1.2. Recommendation

In order to defend against these types of attacks, we recommend that A>B>A embeds which wish to use SameSite=None cookies in a nested frame must call the Storage Access API first, which will grant access without prompting the user in this particular case.

3.2. Navigating a Cross-Site Embed to a Same-Site Frame

Another SameSite=None cookie use case with diverging browser behavior is navigation requests for cross-site embedded frames to a same-site page.

Currently, all major browsers will send the SameSite=None cookie in these navigations. Should this be included in a spec as standard behavior?

3.2.1. Security Considerations

The ability of a cross-site iframe to force the top-level window to embed an arbitrary same-site endpoint as an iframe does not introduce a major risk of cross-site leaks -- the attacker does not gain capabilities to learn information about the data loaded in the iframe. The primary risk in this context is CSRF due to the possibility of initiating a credentialed navigation (via either a GET or POST request) to arbitrary same-site destinations. This could be mitigated by allowing credentialed GET navigations, but restricting the sending of cookies on POST requests (most state-changing actions require non-safe methods such as POST).

Another potential attack in this scenario is clickjacking through iframing an unexpected same-site endpoint with state-changing functionality executed upon a user interaction with the embedded document. However, the A > A relationship between top-level site and iframe generally does not allow attackers sufficient control over the embed to execute compelling attacks, substantially reducing the risk of such attacks.

3.2.2. Recommendation

Given the relatively low risk from this behavior and the lack of an alternative opt-in method, we should send SameSite=None cookies by default here. We could aim to not send cookies for POST requests in this scenario, however, that might have a reduced effect depending on the feasibility of blocking cookies in the top-level cross-site POST requests scenario outlined below.

3.3. Top-Level Cross-Site POST Requests

Another SameSite=None cookie use case is when site A initiates a cross-site POST request to B which is also a top-level navigation.

In this case, the question is whether we want to have the browser send site B’s SameSite=None cookies in the POST request. All major browsers currently do.

There seems to be very widespread usage of this pattern on the web, such as for online credit card payments via 3-D Secure.

3.3.1. Security Considerations

As outlined in the previous section, POST requests usually change server state and as such are especially vulnerable to CSRF attacks via top-level navigation. SameSite cookies exist as a protection mechanism for this attack.

3.3.2. Recommendation

Given the existing widespread usage and lack of clear alternatives, we recommend following the current state of the web and not blocking cross-site cookies in this scenario. In the future, we would encourage use of some sort of preflight mechanism.

4. Implementation Considerations

4.1. Changing Third-Party Cookie Blocking to Use "Site For Cookies"

RFC 6265 bis defines algorithms in section 5.2 to compute the "site for cookies" for a particular HTTP request. The result of this computation is used to determine which cookies are attached to requests based on their SameSite attribute. Cookies set with SameSite=Lax/Strict are sent in requests whose URL is same-site with the corresponding site for cookies, i.e. same-site requests. SameSite=None cookies are allowed in all contexts, including when the request URL is cross-site with the corresponding site for cookies, i.e. cross-site requests.

Our recommendation is to standardize third-party cookie blocking to use site for cookies to determine if a request is same-site or cross-site. Doing so will prevent third-party embeds from being able to send credentialed requests to the top-level site by default.

4.2. Request Storage Access for A>B>A Embeds

We recommend for ABA embeds (see "Cross-site interaction scenarios" section) to allow the inner embed which is same-site with the top-level URL to regain access to cookies by calling the Storage Access API. Since the embed invoking the API is same-site with the top-level URL, the request can be auto-granted with no impact on user privacy. Requiring that the Storage Access API be invoked provides a strong security signal that the top-level URL consents to sending their own credentials from a request that spawned within a third-party embed.

4.3. Heuristics Temporarily Allowing Third-Party Cookies

Some browsers, including Chrome, have implemented heuristics that temporarily grant access to third-party cookies based on confidence signals that the cookie is being used for critical user journeys on the site and not for tracking purposes. [HEURISTICS]

While these heuristics will help websites stay functional during the period the web is transitioning away from third-party cookies, they have the potential to negate some of the security protections of removing third-party cookies. Developers should take care to ensure the flows that rely on these heuristics do not unwittingly expose their site’s state to attackers.

4.4. Enterprise Policies

Browsers may support enterprise policies which disable third-party cookie blocking entirely. One example is the BlockThirdPartyCookies policy in Chromium. [BLOCKTHIRDPARTYCOOKIES] These policies will be necessary to keep critical business functionality for enterprises during the transition away from third-party cookies, especially in organizations which may not be able to push software updates to account for the change in a reasonable amount of time. However, these policies leave enterprise users vulnerable to CSRF or other attacks that result from cross-site boundary leaks. Browsers and web developers will have to consider the additional risk these users are subject to.

5. Acknowledgements

The following is an incomplete list of those works:

[CHIPS], [CLICKJACKING], [CORS-FOR-DEVELOPERS], [CSRF], [FULL-THIRD-PARTY-COOKIE-BLOCKING], [HARDWARE-LEVEL-VULNERABILITIES], [LOGIN-CSRF], [LOGOUT-CSRF], [POST-SPECTRE-WEB-DEVELOPMENT], [SAFE-HTTP-METHODS], [STORAGE-ACCESS-API], [STORAGE-ACCESS-HEADERS], [TARGETED-DEANONYMIZATION], [XS-LEAKS], [XSHM], [XSS]