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

Re: CSP3: DOM API Strawman

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>
Message-ID: <87zj917zl3.fsf@cs.stanford.edu>
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.

Received on Friday, 30 January 2015 02:49:22 UTC

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