[rfc6265bis] Inconsistent browser behavior with secure and prefix cookies (__Host- and __Secure-) on localhost

[Pedro-Bernardo]

We are reporting inconsistent browser behavior regarding Secure cookies and __Host- and __Secure- prefixed cookies on http://localhost.

rfc6265bis-12 delegates the decision of what is a "secure protocol" to the user agent when describing how to handle cookies with the Secure attribute.
Section 5.6

13. If the scheme component of the request-URI does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely.

Section 5.7.3

If the cookie's secure-only-flag is true, then the retrieval's URI's scheme must denote a "secure" protocol (as defined by the user agent).

NOTE: The notion of a "secure" protocol is not defined by this document. Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS. For example, most user agents consider "https" to be a scheme that denotes a secure protocol.

The secure-only-flag affects both cookies with the Secure attribute and cookies with name prefixes (__Host- and __Secure-). rfc6265bis-12 states the following (Section 5.6):

20. If the cookie-name begins with a case-insensitive match for the string "__Secure-", abort these steps and ignore the cookie entirely unless the cookie's secure-only-flag is true.

21. If the cookie-name begins with a case-insensitive match for the string "__Host-", abort these steps and ignore the cookie entirely unless the cookie meets all the following criteria:

    1. The cookie's secure-only-flag is true.
    2. The cookie's host-only-flag is true.
    3. The cookie-attribute-list contains an attribute with an attribute-name of "Path", and the cookie's path is /.

Inconsistent Browser Behavior

According to our tests:

• Firefox allows Secure cookies to be set/sent on http://localhost, as well as __Host- and __Secure- prefixed cookies.
• Chrome also allows cookies to be set/sent with the Secure attribute. However, __Host- and __Secure- cookies are not allowed.
• Safari does not allow Secure cookies to be set/sent, and consequently, __Host- and __Secure- cookies are also discarded since they require that the cookie's secure-only-flag be set to true via the Secure cookie attribute.

The table below summarises browser behavior when setting cookies on http://localhost, localhost subdomains, and http://127.0.1.

Browser	Secure attribute cookie	__Host- prefix cookie	__Secure- prefix cookie
Safari	❌	❌	❌
Chrome	✅	❌	❌
Firefox	✅	✅	✅

Overview

We noticed these inconsistencies after interacting with developers of Web frameworks while discussing cookie integrity issues. Allowing cookies with the Secure attribute and cookie name prefixes to be used on http://localhost, would enable adopters of Web frameworks to test their applications locally, removing the burden of setting up HTTPS locally to use these security features.

As shown in the table above, Firefox fully supports this behavior, while Chrome's support is still partial.

Following bug report (1618113), Firefox moved from a "secure protocol" check when handling Secure cookies, to using the definition of potentially trustworthy origin defined in the Secure Contexts specification, where localhost is considered "Potentially Trustworthy".

The HTML Standard states that:

An environment environment is a secure context if the following algorithm returns true:
...
2. If the result of Is url potentially trustworthy? given environment's top-level creation URL is "Potentially Trustworthy", then return true.

3. Return false.

Chrome made the same decision following Issue 1056543, and support for __Host- and __Secure- prefixed cookies on localhost has been deemed "in scope" (Issue 1245434).

Safari is aware of this inconsistency, but there is still no decision regarding changing their behavior (Bug 232088, Bug 218980, Bug 231035).

As the cookie specification does not clearly define the behavior on localhost, we could consider reusing the notion of 3.1. Is origin potentially trustworthy? from the Secure Context specification, instead of suggesting a user-agent-dependent "secure protocol" check on the scheme of the request-URI, in point 13 of Section 5.6. Storage Model.

Best regards

[sbingler]

I think it's reasonable to modify the phrasing to include potentially trustworthy origins.