Web-Facing Change PSA: Reject cookies with empty name and ambiguous serialization

[Lily Chen]

Hello blink-dev,

This is a PSA that the following change to cookie parsing has shipped in Chromium in M148: crrev.com/c/7698176 

Summary:

A cookie line of the form "=Foo=Bar; <attributes>" is now rejected in parsing, both in HTTP Set-Cookie headers and JavaScript APIs such as `document.cookie`.

Details:

Previously, a cookie line such as "=Foo=Bar" would be parsed as a cookie with an empty name and a value "Foo=Bar". This cookie value is ambiguous, because such a cookie is serialized (to be sent in a Cookie header) as "Foo=Bar", which appears identical to a cookie whose name is "Foo" (with value "Bar"). This is problematic when such an ambiguous cookie shadows a different cookie that the server considers more privileged.

A special case of this serialization ambiguity was previously addressed in crbug.com/40060319 for cookie lines that might shadow "__Host-" and "__Secure-" prefixed cookie names, by rejecting such cookies at creation time. The present change applies the same approach to all such ambiguous cookies: a cookie line whose first semicolon-delimited substring (containing its name and value) begins with an equals sign and contains at least one other equals sign will now be rejected at parsing time.

Web compatibility and interoperability:

The current prevalence of "=Foo=Bar" cookies is extremely rare: a UseCounter shows that about 0.00006% of page visits result in attempting to set such a cookie. (On the other hand, cookies simply having an empty name are a superset of these ambiguous "=Foo=Bar" cookies and are set on about 0.4% of page visits. This change does not affect cookies with an empty name that do not contain an equals sign in their value.)

We will follow up with proposed changes to specification text and Web Platform Tests.

Thanks,

Lily

o.b.o. Chromium //net/cookies maintainers

[PhistucK]

> because such a cookie is serialized (to be sent in a Cookie header) as "Foo=Bar",

How come? Where has the first equals sign gone?

Is that the same across browsers?

☆PhistucK

--
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/CAE24OxxH6suOcDUpomtPTsQPUn_wWHHKO_Q%2BFJdcKsyLZujffw%40mail.gmail.com.

[Lily Chen]

Sorry for the delayed response. 

On Thu, Jun 4, 2026 at 5:10 PM PhistucK <phis...@gmail.com> wrote:

> because such a cookie is serialized (to be sent in a Cookie header) as "Foo=Bar",

How come? Where has the first equals sign gone?

In RFC 6265bis section 5.8.3, the procedure for serializing a cookie for the Cookie header field specifies that the "=" typically inserted between the name and value is only emitted if the name is non-empty.

 

Is that the same across browsers?

According to the latest WPT.fyi runs, Chrome/Edge/Firefox/Safari now all reject the cookie "=test=2" (the change that made Chromium behave this way was announced in this PSA). Firefox/Safari also reject "=test2c", but Chrome accepts it and serializes it as mentioned above, outputting "test2c".

So it seems that Firefox/Safari don't accept cookies with an explicitly empty name (like "=Foo" or "=Foo=Bar") at all, whereas Chrome/Edge reject "=Foo=Bar", but accept "=Foo" and serialize it as a cookie with empty name as specified in RFC 6265bis.

It also seems that browsers currently behave inconsistently for a cookie line without any equals sign (like "Foo" or "test11"): Chrome/Edge treat it as a cookie with empty name and value "test11" (serialized as "test11"), Firefox treats it as a cookie with name "test11" and empty value (serialized as "test11="), and Safari rejects it altogether. On this topic RFC 6265bis, section 5.6 says: "If the name-value-pair string lacks a %x3D ("=") character, then the name string is empty, and the value string is the value of name-value-pair" although section 4.1.1 warns that servers "MUST NOT produce nameless cookies (i.e.: an empty cookie-name) as such cookies may be unpredictably serialized by UAs when sent back to the server".