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

Re: HTML Imports and CSP

From: Mike West <mkwst@google.com>
Date: Thu, 2 Apr 2015 08:50:29 +0200
Message-ID: <CAKXHy=cyGhuqh-DBib4=Dzh9nMga3iZhSwG3bK2sHPQmBftsHg@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Justin Fagnani <justinfagnani@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Apr 2, 2015 at 6:32 AM, Devdatta Akhawe <dev.akhawe@gmail.com>

> > Sure, why not? I'm not a huge fan of inline event handlers, but I don't
> > think that allowing them (and inline script) in Imports actually
> increases
> > the risk a developer exposes herself to. Do you think that's an incorrect
> > analysis?
> There is a huge difference in risk of XSS in inline event handlers and
> inline scripts. Different types of contexts, nested contexts etc all
> are issues. *cough* I think Joel wrote a paper about this :D

You're not wrong there; inline event handlers are bad and they should feel

That said, is the risk really different in kind from just allowing plain
old inline script that executes directly? It doesn't seem to be. Allowing
one without allowing the other seems capricious.

> > There's a difference between supporting a new feature which isn't
> currently
> > covered by any directive, and changing the meaning of a directive that
> > already covers a featue.
> Again, because of the DOMXSS risk (even just injecting a new inline script
> tag
> without nonce), I think not using a new directive messes up the
> security invariants for any CSP adopters.

If we move imports from `script-src` to `import-src`, then sites that
currently disallow imports will no longer have that protection. That seems

What's your ideal solution?

Received on Thursday, 2 April 2015 06:51:17 UTC

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