Intent to Implement and Ship: Http cookie prefix

[Yoav Weiss (@Shopify)]

Contact emails

yoav...@chromium.org

Explainer

This will add the cookie name prefix `__Http-`.

Cookies that would start with that prefix would only be able to be set using the `Set-Cookie` HTTP header and will have to have an `httpOnly` attribute.

Adding that prefix to the cookie name will give site operators the guarantee that any such cookie they see was set by their server, and not be a malicious/compromised script.

There are still ongoing discussions about the exact spelling of a combination of this prefix with the `__Host-` prefix. I'd like this intent to cover both, but I'm not planning to ship the `__HostHttp` variant until the dust settles on the desired spelling.

Specification

https://github.com/httpwg/http-extensions/pull/3110

Summary

There are cases where it's important to distinguish on the server side between cookies that were set by the server and ones that were set by the client. One such case is cookies that are normally always set by the server, unless some unexpected code (an XSS exploit, a malicious extension, a commit from a confused developer, etc.) happens to set them on the client. This proposal adds a signal that would enable servers to make such a distinction. More specifically, it defines the __Http and __HostHttp prefixes, that make sure that a cookie is not set on the client side using script.

Blink component

Internals>Network>Cookies

TAG review

None, as the TAG doesn't typically review HTTP features.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

No particular compat issues, as we don't expect this prefix to already exist in the wild.

In terms of interop, Mozilla and Apple folks are heavily involved in the discussions and haven't raised any concerns.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1256)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/518)

Web developers: Positive (https://lists.w3.org/Archives/Public/ietf-http-wg/2025JanMar/0146.html)

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://chromium-review.googlesource.com/c/chromium/src/+/6638647/15/third_party/blink/web_tests/external/wpt/cookies/prefix/__Http.https.html

https://chromium-review.googlesource.com/c/chromium/src/+/6650996/2/third_party/blink/web_tests/external/wpt/cookies/prefix/__HostHttp.https.html

Flag name on about://flags

None

Finch feature name

PrefixCookieHttp, PrefixCookieHostHttp

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/426096760

Estimated milestones

Shipping on desktop	140
Shipping on Android	140
Shipping on WebView	140

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5170139586363392?gate=5174068239925248

This intent message was generated by Chrome Platform Status.

[Vladimir Levin]

On Thursday, June 19, 2025 at 9:48:37 AM UTC-4 Yoav Weiss wrote:

Contact emailsyoav...@chromium.org

Explainer
This will add the cookie name prefix `__Http-`.

Cookies that would start with that prefix would only be able to be set using the `Set-Cookie` HTTP header and will have to have an `httpOnly` attribute.

Adding that prefix to the cookie name will give site operators the guarantee that any such cookie they see was set by their server, and not be a malicious/compromised script.

There are still ongoing discussions about the exact spelling of a combination of this prefix with the `__Host-` prefix. I'd like this intent to cover both, but I'm not planning to ship the `__HostHttp` variant until the dust settles on the desired spelling.

Specificationhttps://github.com/httpwg/http-extensions/pull/3110

Summary

There are cases where it's important to distinguish on the server side between cookies that were set by the server and ones that were set by the client. One such case is cookies that are normally always set by the server, unless some unexpected code (an XSS exploit, a malicious extension, a commit from a confused developer, etc.) happens to set them on the client. This proposal adds a signal that would enable servers to make such a distinction. More specifically, it defines the __Http and __HostHttp prefixes, that make sure that a cookie is not set on the client side using script.

What is the behavior if one attempts to set an `__Http`-prefixed cookie from script with this feature? Does it silently fail, or is there an error that is thrown?

 

Blink componentInternals>Network>Cookies

TAG reviewNone, as the TAG doesn't typically review HTTP features.

TAG review statusNot applicable

Risks

Interoperability and Compatibility

No particular compat issues, as we don't expect this prefix to already exist in the wild.

In terms of interop, Mozilla and Apple folks are heavily involved in the discussions and haven't raised any concerns.

I agree that the chance of there being __Http named cookies is very low, but I've been wrong about things like this before :) Do you have any metrics/code searches/etc to validate that this is safe from compat perspective?

 

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1256)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/518)

Web developers: Positive (https://lists.w3.org/Archives/Public/ietf-http-wg/2025JanMar/0146.html)

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests?Yes
https://chromium-review.googlesource.com/c/chromium/src/+/6638647/15/third_party/blink/web_tests/external/wpt/cookies/prefix/__Http.https.html

https://chromium-review.googlesource.com/c/chromium/src/+/6650996/2/third_party/blink/web_tests/external/wpt/cookies/prefix/__HostHttp.https.html

Flag name on about://flagsNone

Finch feature namePrefixCookieHttp, PrefixCookieHostHttp

Rollout planWill ship enabled for all users

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/426096760

Estimated milestonesShipping on desktop140Shipping on Android140Shipping on WebView140

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5170139586363392?gate=5174068239925248

[Yoav Weiss (@Shopify)]

On Wed, Jun 25, 2025 at 4:18 AM Vladimir Levin <vmp...@chromium.org> wrote:

On Thursday, June 19, 2025 at 9:48:37 AM UTC-4 Yoav Weiss wrote:

Contact emailsyoav...@chromium.org

Explainer
This will add the cookie name prefix `__Http-`.

Cookies that would start with that prefix would only be able to be set using the `Set-Cookie` HTTP header and will have to have an `httpOnly` attribute.

Adding that prefix to the cookie name will give site operators the guarantee that any such cookie they see was set by their server, and not be a malicious/compromised script.

There are still ongoing discussions about the exact spelling of a combination of this prefix with the `__Host-` prefix. I'd like this intent to cover both, but I'm not planning to ship the `__HostHttp` variant until the dust settles on the desired spelling.

Specificationhttps://github.com/httpwg/http-extensions/pull/3110

Summary

There are cases where it's important to distinguish on the server side between cookies that were set by the server and ones that were set by the client. One such case is cookies that are normally always set by the server, unless some unexpected code (an XSS exploit, a malicious extension, a commit from a confused developer, etc.) happens to set them on the client. This proposal adds a signal that would enable servers to make such a distinction. More specifically, it defines the __Http and __HostHttp prefixes, that make sure that a cookie is not set on the client side using script.

What is the behavior if one attempts to set an `__Http`-prefixed cookie from script with this feature? Does it silently fail, or is there an error that is thrown?

Similar to existing prefixes, when setting a cookie using `document.cookie`, the only way to know it failed is observing (on the server) it is not present in relevant requests.

Setting such a cookie through the CookieStore API results in a Promise rejection.

 

Blink componentInternals>Network>Cookies

TAG reviewNone, as the TAG doesn't typically review HTTP features.

TAG review statusNot applicable

Risks

Interoperability and Compatibility

No particular compat issues, as we don't expect this prefix to already exist in the wild.

In terms of interop, Mozilla and Apple folks are heavily involved in the discussions and haven't raised any concerns.

I agree that the chance of there being __Http named cookies is very low, but I've been wrong about things like this before :) Do you have any metrics/code searches/etc to validate that this is safe from compat perspective?

I don't have any metrics, and GH search seems to ignore the _ and - parts when searching for `__Http-`..

I agree there's a non-zero change that someone added such a prefix to a cookie (without it being httpOnly), but I think having a Finch flag to be able to turn the feature off in case that turns out to be the case is sufficient.

[Mike Taylor]

LGTM1, but conditioned on the spec work landing before shipping anything.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BRtDnZ9x5izwv8_4xUBOxZrzBd2L8Eh_Cn58dPvd9Ayw%40mail.gmail.com.

[Vladimir Levin]

LGTM2, same conditions

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

LGTM3

LGTM2, same conditions

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BRtDnZ9x5izwv8_4xUBOxZrzBd2L8Eh_Cn58dPvd9Ayw%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5d068f26-f995-4263-b5aa-43bb6fa48065n%40chromium.org.

[PhistucK]

Have you tried searching GitHub with a regular expression? Seems not to ignore anything. :)

https://github.com/search?q=%2F__Http-%2F&type=code

☆PhistucK

--

[Yoav Weiss (@Shopify)]

On Wed, Jun 25, 2025 at 7:37 PM PhistucK <phis...@gmail.com> wrote:

Have you tried searching GitHub with a regular expression? Seems not to ignore anything. :)

https://github.com/search?q=%2F__Http-%2F&type=code

Thanks!! Going over the results, it seems like there's nothing there related to cookies (other than the WPT that testing this very feature).

[PhistucK]

I asked Copilot there and it went over the results itself and found nothing, too. Handy (even if not 100% reliable). :)

☆PhistucK

[Yoav Weiss (@Shopify)]

Just to close the loop, the PR has landed, and the feature is now enabled by default. Thanks all!!

[Yoav Weiss (@Shopify)]

Reviving this thread, as while talking to folks about deploying this I realized we should name `__HostHttp-` to be `__Host-Http-`.

That makes sure that deploying __Host-Http- prefixed cookies maintains host semantics in non-supporting browsers and makes for a progressive enhancement. (rather than requiring complex server side logic to determine the cookie name based on browser and version)

I discussed the rename with WebKit, Mozilla and Chrome engineers on the #cookies matrix channel and everyone seemed on board with it.

I also filed spec PRs as well as WPT.

Since this never hit stable (it landed in 140, which is still in Beta), I suggest to:
* Turn off the feature flag in 140 (either in code with back-merges or on the server-side if Google folks are interested in helping with that).

* Rename the prefix in 141 and enable the flag there.

That would mean that the __Http- prefix would ship in 140 and __HostHttp- ships in 141, but I think that's perfectly fine.

What do y'all think?

P.S. Another thing that seems important for ease of deployment is that supporting browsers would apply the prefix rules to cookies already in their stores when they are upgraded.
I'm planning to change Chromium's implementation to support that, but that doesn't seem extremely web-exposed. Let me know if you think otherwise.

[Mike Taylor]

On 8/11/25 5:27 a.m., Yoav Weiss (@Shopify) wrote:

Reviving this thread, as while talking to folks about deploying this I realized we should name `__HostHttp-` to be `__Host-Http-`.

That makes sure that deploying __Host-Http- prefixed cookies maintains host semantics in non-supporting browsers and makes for a progressive enhancement. (rather than requiring complex server side logic to determine the cookie name based on browser and version)

I discussed the rename with WebKit, Mozilla and Chrome engineers on the #cookies matrix channel and everyone seemed on board with it.

I also filed spec PRs as well as WPT.

Since this never hit stable (it landed in 140, which is still in Beta), I suggest to:
* Turn off the feature flag in 140 (either in code with back-merges or on the server-side if Google folks are interested in helping with that).

* Rename the prefix in 141 and enable the flag there.

That would mean that the __Http- prefix would ship in 140 and __HostHttp- ships in 141, but I think that's perfectly fine.

What do y'all think?

Makes sense to me!

P.S. Another thing that seems important for ease of deployment is that supporting browsers would apply the prefix rules to cookies already in their stores when they are upgraded.
I'm planning to change Chromium's implementation to support that, but that doesn't seem extremely web-exposed. Let me know if you think otherwise.

Will you make sure the RFC is updated to reflect this change?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKsGyqchsfbHrXBLPorj--FaTvtJ4wROsNK2dwgkrUaYg%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

On Wed, Aug 20, 2025 at 4:35 PM Mike Taylor <mike...@chromium.org> wrote:

On 8/11/25 5:27 a.m., Yoav Weiss (@Shopify) wrote:

Reviving this thread, as while talking to folks about deploying this I realized we should name `__HostHttp-` to be `__Host-Http-`.

That makes sure that deploying __Host-Http- prefixed cookies maintains host semantics in non-supporting browsers and makes for a progressive enhancement. (rather than requiring complex server side logic to determine the cookie name based on browser and version)

I discussed the rename with WebKit, Mozilla and Chrome engineers on the #cookies matrix channel and everyone seemed on board with it.

I also filed spec PRs as well as WPT.

Since this never hit stable (it landed in 140, which is still in Beta), I suggest to:
* Turn off the feature flag in 140 (either in code with back-merges or on the server-side if Google folks are interested in helping with that).

* Rename the prefix in 141 and enable the flag there.

That would mean that the __Http- prefix would ship in 140 and __HostHttp- ships in 141, but I think that's perfectly fine.

What do y'all think?

Makes sense to me!

P.S. Another thing that seems important for ease of deployment is that supporting browsers would apply the prefix rules to cookies already in their stores when they are upgraded.
I'm planning to change Chromium's implementation to support that, but that doesn't seem extremely web-exposed. Let me know if you think otherwise.

Will you make sure the RFC is updated to reflect this change?

There's an ongoing discussion at https://github.com/httpwg/http-extensions/pull/3156 

[Mike Taylor]

On 8/20/25 10:42 a.m., Yoav Weiss (@Shopify) wrote:

On Wed, Aug 20, 2025 at 4:35 PM Mike Taylor <mike...@chromium.org> wrote:

On 8/11/25 5:27 a.m., Yoav Weiss (@Shopify) wrote:

Reviving this thread, as while talking to folks about deploying this I realized we should name `__HostHttp-` to be `__Host-Http-`.

That makes sure that deploying __Host-Http- prefixed cookies maintains host semantics in non-supporting browsers and makes for a progressive enhancement. (rather than requiring complex server side logic to determine the cookie name based on browser and version)

I discussed the rename with WebKit, Mozilla and Chrome engineers on the #cookies matrix channel and everyone seemed on board with it.

I also filed spec PRs as well as WPT.

Since this never hit stable (it landed in 140, which is still in Beta), I suggest to:
* Turn off the feature flag in 140 (either in code with back-merges or on the server-side if Google folks are interested in helping with that).

* Rename the prefix in 141 and enable the flag there.

That would mean that the __Http- prefix would ship in 140 and __HostHttp- ships in 141, but I think that's perfectly fine.

What do y'all think?

Makes sense to me!

P.S. Another thing that seems important for ease of deployment is that supporting browsers would apply the prefix rules to cookies already in their stores when they are upgraded.
I'm planning to change Chromium's implementation to support that, but that doesn't seem extremely web-exposed. Let me know if you think otherwise.

Will you make sure the RFC is updated to reflect this change?

There's an ongoing discussion at https://github.com/httpwg/http-extensions/pull/3156 

Perfect, thanks.

[Yoav Weiss (@Shopify)]

Just to close the loop on this, the rename landed and was back-merged into 140. No flags required.

Mozilla similarly renamed their implementation.