Intent to Implement and Ship: Http cookie prefix
Yoav Weiss (@Shopify)
Contact emails
yoav...@chromium.orgExplainer
This will add the cookie name prefix `__Http-`.
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/3110Summary
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>CookiesTAG review
None, as the TAG doesn't typically review HTTP features.TAG review status
Not applicableRisks
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)?
YesIs this feature fully tested by web-platform-tests?
Yeshttps://chromium-review.googlesource.com/c/chromium/src/+/6638647/15/third_party/blink/web_tests/external/wpt/cookies/prefix/__Http.https.html
Flag name on about://flags
NoneFinch feature name
PrefixCookieHttp, PrefixCookieHostHttpRollout plan
Will ship enabled for all usersRequires code in //chrome?
FalseTracking bug
https://issues.chromium.org/issues/426096760Estimated 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).
NoneLink to entry on the Chrome Platform Status
https://chromestatus.com/feature/5170139586363392?gate=5174068239925248
Vladimir Levin
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
SummaryThere 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 componentInternals>Network>Cookies
TAG reviewNone, as the TAG doesn't typically review HTTP features.
TAG review statusNot applicable
Risks
Interoperability and CompatibilityNo 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 risksDoes this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
DebuggabilityNone
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 changesOpen 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 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
SummaryThere 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 CompatibilityNo 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-`..
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
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Chris Harrelson
LGTM2, same conditions
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
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
--
Yoav Weiss (@Shopify)
Have you tried searching GitHub with a regular expression? Seems not to ignore anything. :)