Prevent opaque requests being used in response to client requests

[jakearchibald]

(for "client requests" see https://www.w3.org/Bugs/Public/show_bug.cgi?id=27595)

If an opaque response is used for a client request, it breaks the security model as you can then inspect the contents of the response if it executes script.

Eg: I could respond to a request for my home page with a no-cors response from gmail, then I can catch one of the script requests it makes & respond with my own request that queries page contents.

@annevk we can easily add this to the ServiceWorker spec, but do you think it fits better in the Fetch spec along with rules like 1.2.2 in https://fetch.spec.whatwg.org/#http-fetch ?

Chrome seems to already prevent this happening.

[annevk]

For client requests related to workers this is not possible since those require same-origin responses. I guess the mode for "form" et al is "no-cors" so we do indeed have an issue of sorts there.

Is anything but opaque response okay in those scenarios? E.g. if the SW passes a CORS response back the UA would need to enforce the CORS filtered response limitations otherwise you could embed something in an <iframe> and get more data out of it.

[jakearchibald]

if the SW passes a CORS response back the UA would need to enforce the CORS filtered response limitations otherwise you could embed something in an <iframe> and get more data out of it.

What does an iframe expose that a CORS response wouldn't? I suppose a header such as Link: </styles.css>; REL=stylesheet could be detected as you'd see the request for styles.css.

[annevk]

Yup.

[jakearchibald]

If that's a problem then only allow basic responses.

[annevk]

My reasoning was not very sound I think (removed offending comments). A request for a client is obviously same-origin with the client due to service workers having to be same-origin. Therefore, requiring a basic response seems fine.

@jakearchibald would this change work:

In https://fetch.spec.whatwg.org/#http-fetch we introduce a new substep within step 2 that returns a network error if request is a client request and response's type is not "basic" or "default".

Also paging @nikhilm and @wanderview for additional review.

[ehsan]

LGTM.

[horo-t]

Filed http://crbug.com/474914

[jpjitendrapal]

How one can differentiate if one request is 404 or not in case of opaque type?

[wanderview]

How one can differentiate if one request is 404 or not in case of opaque type?

You cannot differentiate them.

[hanguokai]

A question, I want to use Cache API independently to cache no-cors images(because many CDN images no cors header) in windowed scopes not in service worker. In this condition, fetch's response is opaque. I can use cache.put() to save opaque image to cache, but how can I use this cache to restore image? Service worker can response opaque cache response, but in windowed scopes it can't use opaque image cache to create image or URL.createObjectURL() .

[mkruisselbrink]

Unfortunately you'd need something like whatwg/fetch#49 (i.e. being able to pass a Response object to an img tag) to be able to do that without having a service worker.