Repository navigation
considering adding a proxying concept for service workers #1323
Description
Currently we have a number of request headers and getters that describe the initiator of the request. Some of these are security sensitive; e.g. origin and sec-fetch-site. This works well in traditional sites, but tends to get difficult when service workers are introduced into the mix.
When a site has a service worker that does a passthrough fetch handler (respondWith(fetch(evt.request))) what we really need to do is represent the concept:
"Service worker context B is making a request on behalf of original context A."
It can be difficult to know which context should take precedence when selecting values for the request. Should it have an origin header matching context B or context A? If we choose the SW context B, then we may make unsafe requests appear to be safe. On the other hand, for values like destination we probably need to pick the SW context B in order for CSP to work properly today.
It seems like it might be nice to have some kind of concept and infrastructure for this proxying "request on behalf of another" situation. Perhaps headers could be structured as HEADER: <SW value> (<original value>) in a consistent way. Perhaps there could be CSP that formalizes restrictions like "never permit this SW to issue a non-GET request for a cross-site initiator".
I don't really have a proposal here, but it seems like it might be worth discussing. Folks who might be interested: @arturjanc, @annevk, @mikewest
This was discussed at the recent SW virtual F2F: w3c/ServiceWorker#1604
Activity
annevk commentedon Oct 7, 2021
On the topic of destination, I found #48 (context is the old destination) that gives some idea as to why we didn't want it to be developer-controlled and also (however briefly) discusses the model @asuth suggested of coupling the destination with the response (and making the response opaque in such cases) so it couldn't be abused.
The simplest thing I think we could do here is to make it clear to the server that a service worker initiated the fetch. Perhaps something like Sec-Fetch-Client that'd we only use with service workers (and perhaps only for same origin requests?). Needs some more thought.