W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2014

HTML Imports vs unsafe-inline

From: Jeffrey Yasskin <jyasskin@google.com>
Date: Wed, 10 Sep 2014 21:19:41 -0700
Message-ID: <CANh-dX=qPgwM-w9+K9EvN8bWvK0NDyh6Do784LYbd0r_pdL0RA@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
HTML Imports are a great way to import javascript, but the simple way
to use them requires unsafe-inline:
https://code.google.com/p/chromium/codesearch/#chromium/src/third_party/WebKit/Tools/GardeningServer/lib/update-util.html.
It's possible to split each file in two, but that's inconvenient while
editing and costs network requests. It's also possible to write a
build step that generates hashes for each script, but injecting a
build into the edit/debug cycle slows that cycle down.

Is there something the CSP spec could do (either a new token or advice
to authors) that would make these literal scripts easier to use
without opening vulnerabilities?

This is also relevant to Chrome Apps, which force a CSP to protect
their users: https://developer.chrome.com/apps/contentSecurityPolicy.
If there's something halfway to unsafe-inline that would still avoid
the relevant vulnerabilities but would allow use of literal <script>
tags, it'd be nice to let people use Polymer more easily.

Unfortunately, I don't have a concrete suggestion here, partly because
I don't understand the attacks that the inline-script restrictions are
intended to defend against.

Jeffrey
Received on Thursday, 11 September 2014 04:20:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC