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

Re: Programmatically declaring the CSP of an iframe

From: Mike West <mkwst@google.com>
Date: Tue, 21 Jul 2015 06:31:03 +0200
Message-ID: <CAKXHy=ccDEPc-ChbmioP9WPrAprsr4o4qugDsb5dVO1hAuUZFg@mail.gmail.com>
To: Conrad Irwin <conrad.irwin@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Jul 21, 2015 at 12:37 AM, Conrad Irwin <conrad.irwin@gmail.com>
> I looked into using the sandbox attribute [2], but it suffered from two
> drawbacks:
> a) I can't add event listeners to the contents of the iframe, which is
> necessary for keyboard shortcuts. [3]

Looks like a bug in Chrome rather than a bug with the feature. Does Firefox
support this kind of work?

> b) Tabs opened by the iframe inherit the security policy, so it breaks
> javascript on pages that emails link to. [4]

We're fixing this with a new `allow-popups-to-escape-sandbox` keyword (
https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvments). Should
be shipping in Chrome 46, though I haven't heard signals from other browser
vendors (WDYT, Mozillians? Microsofties? :) )

> So now I'm inserting a Content-Security-Policy using a meta tag on the
> purified document.

At the moment, that's how you'll need to apply a CSP to the page. One of
the goals for CSP3 is to add a real API, but that's a little ways off.

> I would love to be able to specify the Content-Security-Policy from the
> parent document not the loaded document, as that feels cleaner. It would
> also hopefully let me add CSP reports, and other features that are not
> supported by meta-tag CSP policies.

What would you like to do that you can't from <meta>?


Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Tuesday, 21 July 2015 04:31:51 UTC

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