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