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

I know that `Set-Cookie` headers cannot be set on `Response` objects in a SW (before sending those back to the calling page).

My question, which I have been unable to find a definitive answer to, is... why?

I have seen multiple discussion threads (here and elsewhere around the web) that seem to center around trying to provide different APIs for setting/getting cookies asynchronously, even in SW. I guess that's now `CookieStore`, which is currently in some but not all browsers.

Was the desire to design/build this more general purpose API the sole reason for filtering `Set-Cookie` filters from `Response objects? Or was there some bigger security concern driving that? Would certainly appreciate pointers to the justifications.

----

I think wanting to set a cookie header into a response object sent from a SW to the page is... a different use case... than the general desire to read/set cookies from SW/JS (i.e. `CookieStore`).

In particular, I have a use-case for wanting my SW to be able to, on a certain response it has intercepted, add an "http-only" cookie to the response, just as if the server itself had set `httpOnly` on the cookie in its response. In doing so, that cookie should then be transparently exchanged for all request/response round-trips between the browser and server, but no other JS should be able to see/access this cookie.

Effectively, this is a sort of "write only" type of API use-case, where you want the JS to be able to set it, but NOT be able to read it.

As far as I can tell, the `CookieStore` API doesn't allow a SW to set a cookie as `httpOnly`. So I don't think there's any way to do what I'm trying to do.

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

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