- From: Deian Stefan <deian@cs.stanford.edu>
- Date: Thu, 29 Jan 2015 18:48:56 -0800
- To: Mike West <mkwst@google.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
- Cc: Alex Russell <slightlyoff@google.com>, Yehuda Katz <wycats@gmail.com>
Mike West <mkwst@google.com> writes: > I've started putting together a strawman DOM API for discussion: > https://w3c.github.io/webappsec/specs/content-security-policy/#strawman-dom-api > > The current mishmash of IDL should (I think) support everything necessary > for source list directives like `script-src`. It'll need more work to > support things like `sandbox`, `referrer`, etc. There's not enough > explanation, but the general outline of a policy declaration could look > something like: > > // Assuming a Service Worker: > self.addEventListener('fetch', function(event) { > var p = new SecurityPolicy("script-src https://example.com"); > if (!p.allowRequest(event.request)) > event.respondWith(Response.error()); > ... > }); > > I know there's not a lot of detail there, but perhaps it's enough to kick > off a conversation? CCing folks that I know are interested. :) I think that API is pretty reasonable. (Will take a closer look to send you feedback soon.) But its use seems to be closely tied to Service Workers. IMO, this a good use case. I would, however, additionally like to propose that we extend the DOM API to allow code to inspect the current CSP policies. Something along the lines of: partial interface Window { readonly attribute SecurityPolicy contentSecurityPolicy; } It may even be useful to allow code to directly modify the underlying CSP as to add more directives. Best, Deian
Received on Friday, 30 January 2015 02:49:22 UTC