cookieStore.delete() is unable to delete cookies that were set using cookieStore.set(), when invoked on a page whose URL includes a subdomain
Categories
(Core :: Networking: Cookies, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | --- | unaffected |
| firefox137 | --- | disabled |
| firefox138 | --- | disabled |
| firefox139 | --- | verified |
People
(Reporter: dholbert, Assigned: baku)
References
Details
(Keywords: sec-low, Whiteboard: [necko-triaged])
Attachments
(2 files)
STR:
- Be sure you have
dom.cookieStore.enabledset totrue(it's true by default only in Nightly right now, as of bug 1953368). - Visit https://www.example.org/ (note: the "www" subdomain is important for triggering the bug; it doesn't repro if you instead went to example.org)
- Paste and execute the following in your web console:
async function logCookieVal(name, logPrefix) {
let result = await cookieStore.get(name);
let message = `${logPrefix}, got ${result}`;
if (result && result.value) {
message += ` (value = '${result.value}')`;
}
console.log(message);
}
logCookieVal("foo", "Expecting to be initially null");
await cookieStore.set("foo", "bar");
logCookieVal("foo", "Expecting to show value bar");
await cookieStore.delete("foo");
logCookieVal("foo", "Expecting to be null after deletion");
ACTUAL RESULTS:
This is my log output:
Expecting to be initially null, got null
Expecting to show value bar, got [object Object] (value = 'bar')
Expecting to be null after deletion, got [object Object] (value = 'bar')
EXPECTED RESULTS:
The last line there should've shown "got null" to report that the cookie was removed. i.e. the cookie should have been deleted.
Notes:
- I initially ran into this when poking at bug 1949743 (a WebCompat Site Report for an Enphase website); I posted some diagnostic notes over there (bug 1949743 comment 19) before realizing I could repro this on www.example.org as well.
- I'm pretty sure this isn't actually the cause of that enphase bug -- in part because I can still reproduce the user-facing issue at the Enphase site even if I disable the cookieStore about:config pref. (Hence, spinning this off as a separate bug.)
- I'm filing this as security-sensitive since I see that we've got a similar-sounding issue described in bug 1953368 comment 6 that we're treating as security-sensitive. (This bug here is a case where a site can't delete its own cookie, which is not in-and-of-itself security-sensitive, but I think this is a version of a broader issue that has security implications.)
valentin: I'm not sure if this particular failure case is already known -- if it is, feel free to dupe as-appropriate. Thanks!
| Reporter | ||
Comment 1•1 year ago
|
||
| Reporter | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 2•1 year ago
|
||
I think the spec for .delete() is wrong or incomplete -- looks like it wasn't updated with all the properties nor defaults that match .set(). We might have some bugs of our own on top.
If I go to https://www.example.org and do
let cookie = {name:"foo", value:"bar", domain:"www.example.org", path:"/", partitioned:false};
await cookieStore.set(cookie);
await cookieStore.delete(cookie);
then the cookie gets created but not deleted.
If I change the domain to "example.org" then the above both creates and deletes the cookie. It looks like .delete() is just always using a fixed domain of the eTLD+1, in both forms and ignoring the cookie options even when explicitly set. That would be the problem from bug 1951750, but it looks like D240695 did fix delete() in the same way as set(). I don't know why only set() is behaving as if it's fixed.
We aren't passing the domain to the options in the Delete(), this is maybe expected because we don't explicitly mention the domain when calling await cookieStore.delete("thing"). Maybe we should update the options.domain with the principal's host (not base domain) somewhere around here since the validate domain function is just getting a free pass due to the empty string
Got ahead of myself, it looks like we pull the hostname out of the uri field later on
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 5•1 year ago
|
||
Comment 7•1 year ago
|
||
Updated•1 year ago
|
| Reporter | ||
Comment 8•1 year ago
|
||
VERIFIED FIXED in NIghtly 139.0a1 (2025-04-15)
The STR from comment 0 now produce these EXPECTED RESULTS (notably the final line is now correct):
Expecting to be initially null, got null
Expecting to show value bar, got [object Object] (value = 'bar')
Expecting to be null after deletion, got null
Updated•4 months ago
|
Description
•