- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 19 Jul 2012 12:24:02 -0700
- To: John J Barton <johnjbarton@johnjbarton.com>
- Cc: public-webappsec@w3.org
On Thu, Jul 19, 2012 at 11:17 AM, John J Barton <johnjbarton@johnjbarton.com> wrote: > On Thu, Jul 19, 2012 at 10:54 AM, Adam Barth <w3c@adambarth.com> wrote: >> If you want to use eval, you can enable it by listing 'unsafe-eval' >> (with the quotes) in the script-src part of your CSP policy: >> >> default-src 'self'; script-src 'self' 'unsafe-eval' > > Thanks for the suggestion. However this option does not seem to be allowed > for Chrome extensions: > http://code.google.com/chrome/extensions/contentSecurityPolicy.html#H2-3 Correct. Chrome extensions limit the sorts of CSP policies you can use. > Any other suggestions? I'd recommend asking on the Chrome Extensions mailing list. I'll be happy to answer your questions there. :) > By the way I object to the name of this option. "unsafe-eval" implies that > eval is unsafe or that the CSP user intends to use eval in an unsafe manner. > Neither of these is true for any practical users of CSP. The problem is not > eval(), it is inadequate vetting of content obtained over the network. Empirically, use of eval is unsafe. According to a recent study conducted before the migration to mainfest_version 2, about 1% of Chrome Extensions contained XSS because of their use of eval. Adam >> On Thu, Jul 19, 2012 at 10:45 AM, John J Barton >> <johnjbarton@johnjbarton.com> wrote: >> > Hi. I was looking into converting my application to use CSP when I >> > learned >> > that neither eval nor new Function() are allowed. I have a large >> > application >> > that uses these features to compile JS at runtime. I am wondering what >> > alternatives are available. >> > >> > Thanks, >> > jjb > >
Received on Thursday, 19 July 2012 19:25:08 UTC