| Internet-Draft | Origin-Bound Cookies | October 2025 |
| Gill | Expires 18 April 2026 | [Page] |
This draft introduces Origin-Bound Cookies which updates [COOKIES] aiming to make cookies more secure by default through binding cookies by port and scheme.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://amarjotgill.github.io/origin-bound-cookies/draft-amarjotgill-origin-bound-cookies-protocol.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-amarjotgill-origin-bound-cookies-protocol/.¶
Source for this draft and an issue tracker can be found at https://github.com/amarjotgill/origin-bound-cookies.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 18 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Cookies are one of the few components of the web platform that are not scoped to the origin by default. This difference in scoping means that cookies have weak confidentiality compared with other storage APIs on the web platform.¶
https://somesite.com sets a simple cookie, secret=123456, which contains private information about a user. Information that an attacker wishes to learn. To do so the attacker man-in-the-middles the user, and then tricks them into visiting http://somesite.com (note the insecure scheme). When the user visits that page their browser will send the secret cookie and the attacker can see it.¶
Similarly, if the attacker has somehow compromised a service running on a different port on the same server, let's say port 345, as https://somesite.com then they could trick the user into visiting https://somesite.com:345, the user's browser will send the secret cookie, and once again the attacker can see it. Even more, through the same techniques, an attacker can also modify a user's cookies, sending a Set-Cookie field instead of simply eavesdropping.¶
All of these examples are possible because cookies by default do not care about the scheme or port of their connection. As long as the host matches the cookie will be accessible.¶
This document proposes changes to [COOKIES] by binding cookies to port and scheme which will prevent against these attacks and greatly improve cookie security.¶
An aliasing cookie refers to a cookie which shares the same cookie-name, cookie-value and sub domain with another cookie but differs via scheme or port.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
First, alter Section 5.1.2 of COOKIES by adding port to the Cookie Struct, this would be necessary to keep track of the port the cookie was set on.¶
Below is the definition of the port attribute.¶
A cookie's port is either null or a 16-bit unsigned integer. It is initially null.¶
For port matching algorithms below will be updated to compare integers to ensure port values match. Pre-existing cookies with unspecified "port" will have a null value. This value will cause the cookie to be treated with legacy behavior (The cookie will not be bound to port).¶
Example:¶
The new behavior will behave as the following.¶
A cookie set by origin https://example.com will only ever be sent to https://example.com(:443). It will never be sent to a different port value such as https://example.com:8443.¶
First, alter Section 5.1.2 of COOKIES by adding scheme to the Cookie Struct, this would be necessary to keep track of the port the cookie was set on.¶
Below is the definition of the scheme attribute.¶
A cookie's scheme is null or a byte sequence. It is initially null.¶
Pre-existing cookies with unspecified "scheme" will have a null value. This value will cause the cookie to be treated with legacy behavior (The cookie will not be bound to scheme).¶
Example:¶
The new behavior will behave as the following.¶
A cookie set by origin https://example.com will only ever be sent to https://example.com. It will never be sent to a different scheme value such as http://example.com.¶
We update the storage model in Section 5.4.3 of COOKIES to ensure that port and scheme are being considered when comparing with existing cookies.¶
Step number 18 of this section will need to be altered to:¶
If the user agent's cookie store contains a cookie oldCookie whose name is cookie's name, host is host-equal to cookie's host, host-only is cookie's host-only, path is path-equal to cookie's path, and scheme is equal to cookie's scheme¶
A new substep should also be added to step number 18:¶
If cookie's host-only is set to true and port does not equal cookie's port then skip the remaining sub-steps.¶
Note the addition of checking port and scheme, this will prevent a cookie with differing port or scheme values from overwriting the oldCookie, instead this cookie would be stored as a separate cookie and the oldCookie will not be deleted. Also note if the domain attribute is set then we will ignore checking via port so it will overwite the oldCookie.¶
Origin-Bound Cookies is considered net positive for security, the following would be mitigated by it.¶
Weak integrity: This occurs when an insecure site, controlled by a network attacker, sets a malicious cookie that is then sent to the secure version of that site. OBC binds cookies to their setting origin, preventing such malicious cookies from being accessed by a different origin.¶
Weak confidentiality: This refers to an attacker reading sensitive user data set by a secure site, which is unintentionally sent to an insecure site. OBC ensures that cookies are only accessible by the same origin that set them, preventing this type of data leakage.¶
One security concern is how to handle clients that require the use of cookies across origins, this is handled by the following, when a cookie has a valid Domain attribute specified (hereby called a “domain cookie”) that cookie has relaxed bindings. Namely, the cookie may be sent to:¶
any host which domain matches the Domain value (This is unchanged from legacy behavior)¶
any port value¶
Importantly a domain cookie is still bound to the scheme of its setting origin.¶
This behavior allows developers to opt-out of the stronger protections of an origin cookie which can help with compatibility for usages that need a particular cookie available across hosts and/or ports.¶
Origin binding cookies will obsolete the purpose of Secure but this proposal will not remove support for Secure. Removal for Secure could be a possible future consideration for the HTTP WG.¶
This document has no IANA actions.¶
The editors would also like to thank the following individuals for feedback, insight, and implementation of this draft and its predecessors (in alphabetical order): Dylan Cutler, Johann Hofmann, Mike West, Steven Bingler,¶