Re: CSP, Fetch, and Service Workers

On Wed, Mar 26, 2014 at 2:01 AM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:
>
> > 2) We have to carefully consider how large parts of CSP are no longer
> > effective in the world of service workers. You no longer have the
> > close tie between an API that initiates the fetch and the response.
>
> Where does CSP fall with a SW? Does it run after the SW or before SW?
> I.e., if SW makes a request to alice.com will the page's CSP apply to
> that request? If a page makes a request to alice.com, will CSP apply
> before the request hits the SW?
>

CSP can't deal with the request before it hits SW, because this is also
before redirects can occur, and CSP acts post-redirect.

If a navigation falls under the scope of a SW, it can handle the request.
If that page makes a resource request to alice.com, it will have the option
to handle that request (even if it's on another origin).

If the SW chooses not to handle the navigation request, I guess it's
business-as-usual for CSP. If the SW does handle the request, it can do any
of the following:

* Serve a response from any origin + url (must be non-opaque for
navigations)
* Construct a response manually
* A combination. Eg take a non-opaque response and modify bits before using
it

For navigations, this means the SW can do what it wants with
the Content-Security-Policy header of the response. If a particular
resource request isn't handled by SW, it's business-as-usual for CSP,
although the Content-Security-Policy may have been set/modified by the SW
on page response.

CSP may say "only allow scripts from example.com", but SW allows me to
respond to <script src="http://example.com/hello.js"> with a response from
http://foobar.com/blah.js. I could construct a response manually which may
contain all or parts of http://foobar.com/blah.js if CORS allows it. I'm
not sure it makes sense for CSP to get involved in responses served by the
SW.

CSP could limit the requests SW could make, which would in turn limit the
kind of responses it could serve. Maybe connect-src is that rule. However,
these rules must come from the Content-Security-Policy header of the worker
script rather than the page, which cannot be modified by a SW.

For Workers, CSP says use the policy of the owning document, however SW
doesn't have an owner document (I guess SharedWorkers have the same issue).

Maybe we need a CSP rule for SW registrations. They're already limited to
the same origin, but maybe you'd want to limit that further or disable it
all together. However, if registration is limited to
/foo/bar/whatever/worker.js, that worker could serve a page that relaxes
that rule and re-register.

Jake.