Exposing Sec-Fetch headers to Service Workers via Request().Headers()

[arturjanc]

Authors can use Service Workers and the Cache API to serve responses from the cache in a SW; when this happens an attacker may be able to make a request to the target origin and have the response served by that origin's SW. If a response was previously cached for a same-origin request, but the SW responds with the same data to a cross-site request, it could return a sensitive resource to the attacker, allowing her to learn information via the usual information leak vectors.

Should we consider exposing the values of Sec-Fetch-* headers via the Headers() API to allow developers to implement logic in SWs similar to what they may have server-side? I think this should be safe, but we should definitely think about this.

[mikewest]

In Chrome, we've modeled these headers as being attached at the time we hit the network, so they're not visible in Service Workers. This would be a little bit hard to change given the point at which we attack Sec-Fetch-Site. That's a practical objection for one implementation, though. I don't have any philosophical objection to adding headers early, but I worry a bit about Service Workers being able to modify the headers before they're sent out to the network... Reading doesn't seem like a problem, but writing would be.

/cc @anforowicz.

[arturjanc]

Yeah, if we do this, the Sec-Fetch-* headers should be read-only (I think most other headers exposed on the Request object are read-only as well, though I could be wrong).