[whatwg] [Workers] CSP and SharedWorkers
jaffathecake at gmail.com
Thu Sep 26 06:57:33 PDT 2013
The registration of a Service Worker is currently only possible via DOM
call from an HTML document, so it makes sense for registration to be
governed by CSP.
There was some discussion here
So script-src would cover registration, but there was also suggestion that
x-domain controllers would be disallowed be default, and enabled by
script-src or perhaps an additional controller-src CSP directive.
Note, this only covers registration. If http://example.com allows
controllers from http://example.co.uk, and successfully calls
registerServiceWorker("/*", "http://example.co.uk/service.js"), that
controller will be used for all top-level fetches on http://example.com,
and all fetches originating from documents on http://example.com,
regardless of their CSP headers.
The browser will re-fetch (ugrade) and continue to use
http://example.co.uk/service.js even if the CSP rules are changed to
disallow controllers from that url. But if a page attempts to register a
new controller, the url must be allowed by CSP.
Does script-src apply to importScripts in Workers currently? The spec
doesn't explicitly mention it, feels like it should. I don't have a strong
opinion on whether Workers should have their own CSP.
Seems sensible for SharedWorkers to obey their own CSP headers and ignore
those of the constructing/registering page (except for the actual
constructing/registering of course). script-src should apply for
importScripts and imported scripts would use the rules of the top-level
SharedWorker. connect-src should also apply to fetch (
On 26 September 2013 13:53, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey <me at kylehuey.com> wrote:
> > Thoughts?
> What happens today for <iframe>? The load itself seems to be governed
> by the parent. Does the policy inherit into it? I feel like workers
> should work like <iframe> as they're essentially their own global
More information about the whatwg