Re: [w3c/ServiceWorker] Is there a security issue justifying no `Set-Cookie` setting in SW? (Issue #1649)

> a service worker can not only intercept requests to its own origin, but also subresource requests to any other origin

It's not super clear to me why that would be a privacy or security concern, but OK I get that it would possibly not need to be allowed for cross-origin requests. Perhaps (just thinking out loud) if the response from that other origin had included CORS headers allowing the page in question to access the response *contents*, maybe that should be enough to justify allowing the SW to access (and modify) all its headers, including `Set-Cookie`?

But, yes, in my case I only care about setting cookies on my same-origin request/response pairs.

> Also semantics might be weird; service workers can reply to requests with responses containing Set-Cookie headers already (just not synthetic responses). It's just that today Set-Cookie headers are only parsed when the response comes from the network, and not even when for example a response is loaded from the network cache.

I may be missing something or misunderstanding, but I don't think a SW can ever add/modify cookies on a response, even a "real one that came from the network", before handing that response back to the page.

I think I've definitely tried exactly that in the past and the setting of the cookie from the SW was completely ignored as far as I could tell -- couldn't see it in devtools for the page, and the cookie didn't end up going back to the server on the next request.

I would expect that setting cookie headers on a response, while in a SW, should work whether that response was real from a server or whether that response was synthetic.

I don't see why it should be "awkward", whether it was a real response or a synthetic one. You add a header to the response, and like all headers, it augments (or overrides) existing headers. I think (IIRC) that adding an additional `Set-Cookie` header for the same cookie name either modifies or deletes (if set to empty value), so I think that covers all the relevant use-cases for modification. And for reading the values (any not marked http-only), we have the aforementioned `CookieStore` API, right?

Again, I guess I would ask, what security concern would arise if a SW was able to create synthetic responses with cookies to give back to the page? That kind of thing seems quite useful to me.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1649#issuecomment-1176778938
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1649/1176778938@github.com>