W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Service workers and CSP

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 27 Jan 2015 14:22:29 +0100
Message-ID: <CADnb78gfdj-56Bu36feD6Ck1x-wmbLmhA0b4uVrYRqDj1BP0qQ@mail.gmail.com>
To: WebAppSec WG <public-webappsec@w3.org>
Cc: Jake Archibald <jaffathecake@gmail.com>, Alex Russell <slightlyoff@google.com>, Jungkee Song <jungkees@gmail.com>
Given a worker A and its service worker SW the path to the network is:

  A -> SW -> network

Both A and SW can have a CSP policy.

If SW's fetch event is not handled the effective path to the network is:

  A -> network

An equivalent to that was going to be event.default() but that does
not work: https://github.com/slightlyoff/ServiceWorker/issues/607

This means that enabling SW makes A's CSP policy a lot less useful. I
think we already acknowledged this to some extent. I'm mostly sending
this to make sure I have not missed anything.

Note that the things we previously thought we could rely on have not changed:

* A synthetic Response object has no url so could be blocked by A
similar to eval et al.
* If a Response object has a url it is the one from the network.

The caveat here is that at the moment we do overwrite this url field
similar to how redirects are handled (step 6 of the main fetch
algorithm). If CSP cannot hook adequately around there we might need
to have an "original url" slot on Response objects or something like

Received on Tuesday, 27 January 2015 13:22:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC