Cookies

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#attributes

Cookie 是由 Set-Cookie: NAME=VALUE; Expires=DATE; Path=PATH; Domain=DOMAIN_NAME; SECURE 组成

Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The SameSite attribute of the Set-Cookie HTTP response header allows you to declare if your cookie should be restricted to a first-party or same-site context.

Note: Standards related to the Cookie SameSite attribute recently changed such that:

• The cookie-sending behavior if SameSite is not specified is SameSite=Lax. Previously the default was that cookies were sent for all requests.
• Cookies with SameSite=None must now also specify the Secure attribute (they require a secure context/HTTPS).
• Cookies from the same domain are no longer considered to be from the same site if sent using a different scheme (http: or https:).

The SameSite attribute accepts three values:

• Lax

Cookies are not sent on normal cross-site subrequests (for example to load images or frames into a third party site), but are sent when a user is navigating to the origin site (i.e., when following a link).

This is the default cookie value if SameSite has not been explicitly specified in recent browser versions (see the "SameSite: Defaults to Lax" feature in the Browser Compatibility).

Note: Lax replaced None as the default value in order to ensure that users have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.

• Strict

Cookies will only be sent in a first-party context and not be sent along with requests initiated by third party websites.

• None

Cookies will be sent in all contexts, i.e. in responses to both first-party and cross-origin requests. If SameSite=None is set, the cookie Secure attribute must also be set (or the cookie will be blocked).

Warnings like the ones below might appear in your console:

Cookie "myCookie" rejected because it has the "SameSite=None" attribute but is missing the "secure" attribute.

This Set-Cookie was blocked because it had the "SameSite=None" attribute but did not have the "Secure" attribute, which is required in order to use "SameSite=None".

The warning appears because any cookie that requests SameSite=None but is not marked Secure will be rejected.

1Set-Cookie: flavor=choco; SameSite=None

To fix this, you will have to add the Secure attribute to your SameSite=None cookies.

1Set-Cookie: flavor=choco; SameSite=None; Secure

A Secure cookie is only sent to the server with an encrypted request over the HTTPS protocol. Note that insecure sites (http:) can't set cookies with the Secure directive.

Note: On older browser versions you might get a warning that the cookie will be blocked in future. For example:

Cookie myCookie will be soon rejected because it has the SameSite attribute set to None or an invalid value, without the secure attribute.

Recent versions of modern browsers provide a more secure default for SameSite to your cookies and so the following message might appear in your console:

Cookie "myCookie" has "SameSite" policy set to "Lax" because it is missing a "SameSite" attribute, and "SameSite=Lax" is the default value for this attribute.

The warning appears because the SameSite policy for a cookie was not explicitly specified:

1Set-Cookie: flavor=choco

You should explicitly communicate the intended SameSite policy for your cookie (rather than relying on browsers to apply SameSite=Lax automatically). This will also improve the experience across browsers as not all of them default to Lax yet.

1Set-Cookie: flavor=choco; SameSite=Lax

hostOnly 属性通常与 cookies 的托管域有关。当一个 cookie 被标记为 hostOnly 时，它只能通过具体的托管域名访问，而不能通过所有的子域名访问。

在许多编程库和框架中，你可能会遇到 hostOnly 属性，尤其是在与 cookies 和会话管理有关的上下文中。

这种限制有助于提高安全性，因为它限制了可以访问 cookie 的域的范围。例如，如果你有一个 cookie 适用于 example.com，而不是所有像 subdomain.example.com 这样的子域，那么通过将该 cookie 标记为 hostOnly，你可以确保它只能通过确切的域名访问。

这里的一个关键方面是它与浏览器的同源策略相互作用，该策略定义了不同域之间如何进行交互。

使用 hostOnly 属性可以有效地隔离不同的子域，并为每个子域提供独立的会话管理。这在安全上可以带来许多好处，因为它减少了攻击面，使跨站点请求伪造（CSRF）和跨站点脚本攻击（XSS）等攻击更难以实施。

• 不设置 domain 代表 hostOnly。
• 不设置 Expires 和 maxAge 代表 session cookie，当客户端关闭时，会话结束，之后会话 cookie 将被删除。

Warning: Many web browsers have a session restore feature that will save all tabs and restore them the next time the browser is used. Session cookies will also be restored, as if the browser was never closed.

• <cookie-name>=<cookie-value>

• Defines the cookie name and its value. A cookie definition begins with a name-value pair.

  A <cookie-name> can contain any US-ASCII characters except for: control characters (ASCII characters 0 up to 31 and ASCII character 127) or separator characters (space, tab and the characters: ( ) < > @ , ; : \ " / [ ] ? = { })

  A <cookie-value> can optionally be wrapped in double quotes and include any US-ASCII character excluding control characters (ASCII characters 0 up to 31 and ASCII character 127), Whitespace, double quotes, commas, semicolons, and backslashes.

  Encoding: Many implementations perform URL encoding on cookie values. However, this is not required by the RFC specification. The URL encoding does help to satisfy the requirements of the characters allowed for <cookie-value>.

Note: Some <cookie-name> have a specific semantic:
__Secure- prefix: Cookies with names starting with __Secure- (dash is part of the prefix) must be set with the secure flag from a secure page (HTTPS).
__Host- prefix: Cookies with names starting with __Host- must be set with the secure flag, must be from a secure page (HTTPS), must not have a domain specified (and therefore, are not sent to subdomains), and the path must be /.