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
that.


-- 
https://annevankesteren.nl/
Received on Tuesday, 27 January 2015 13:22:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:09 UTC