Updating/deleting a cookie with different SameSite value

[kvibber]

https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html

I've been reading over steps 17, 18 and 22 of the storage spec to try and figure out whether it actually says the SameSite value must be matched when setting a matching cookie.

If I'm reading it correctly, it should be possible to update a cookie that has SameSite=none;Secure with a new cookie that has neither as long as the cookie came from a matching context.

But that doesn't seem to be the case: There are a lot of posts online about having to use the same attributes even when you delete a SameSite=none cookie. (Firefox seems to be merging the attributes as far as I can tell, taking SameSite=none from the previous cookie and applying the must-be-secure rule to the new one, but is currently just throwing a warning in the console log.)

If the intent is to require updates and deletions to match the attributes, I can't find it in the spec, and if the intent is to leave it up to the user-agent, I don't see that either.

[sbingler]

Hi,

Cookies can be thought of as having two types of access permissions, read and write. Some attributes on cookies can block access, only when none of the attributes are blocking access can you read or write to the cookie.

To update/delete/overwrite a given cookie you have to have write access permission and then you have to match name, domain, host-only-flag, and path.

You mentioned a cookie withSameSite=None; Secure, so let's use that as an example.

Because of the Secure attribute this cookie is only accessible from what the browser deems a "secure" connection, typically https://. An http:// connection will have its read/write access blocked, but an https:// connection will not.

Secondly this cookie has SameSite=None. Since none provides cross-site access, this cookie can be accessed in any same-site or cross-site context and thus it's not blocked (read or write) in any of those contexts by SameSite

But what if the cookie was SameSite=Lax? In that case this cookie would be inaccessible in a cross-site context (let's say an iframe embedded within some other site). So SameSite would be blocking the read/write accessibility.

So what happens if I change the SameSite value? If I try go from None to something more restrictive I could have read access on the (current) cookie with SameSite=None but I may not have write access on a SameSite=Lax cookie because I'm not in a context that Lax allows. If I don't have write access then I can't create the new cookie.

Let's flesh that example out some more. I start with a cookie:
document.cookie = "a=b; SameSite=None; Secure" which I set on https://example.com

Now I want to modify it, so I run the command
document.cookie = "a=b2; SameSite=Lax; Secure"

whether or not this succeeds depends on the accessibility of cookie a.

Context 1: We're on http://example.com

• This will fail due to the Secure. Whether or not we're same-site or not is irrelevant because Secure will block the accessibility.

Context 2: We're on https://example.com

• This will succeed. We have read access and write access due to the context being same-site. This is a simplistic example, but the same would be true if we had a tree of iframes, all https://example.com, and tried the same command in any of them.

Context 2: We're on https://example.org which is iframing https://example.com (note the .org, that is a different site)

• This will fail. We have read access and can see the cookie a=b but we're unable to write to it due the cross-site context which SameSite=Lax is blocking.
  • So in this case you would have to match the SameSite value, but that's due to the acessiblity rules of cookies. Not some "SameSite must match to overwrite cookie" rule.

I just tried my example in Chrome 102 and it's working as I detailed. If you find a browser or situation that seems to be wrong I encourage you to file a bug.

(Note: Some parts of this were simplified, but hopefully the message is still getting across. Cookies are complicated)

[miketaylr]

I just tried my example in Chrome 102 and it's working as I detailed. If you find a browser or situation that seems to be wrong I encourage you to file a bug.

It sounds like we can close here then. Thanks for filing an issue.