CSP unsafe-inline required to use?

[lol768]

Version

4.1.3

Browser and OS info

Firefox 59.0b8

Steps to reproduce

• Read README
• Attempt to use Vue dev tools on site with strict CSP headers
• Check console for errors:

Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”). Source: ;(function(e){let t={};if(e.hasOwnProper....
Page:1

Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”). Source: ;(function(e){setTimeout(()=>{const n=do....
Page:1

Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”). Source: ;(function(e){let n=null,t=0;const o={no....
Page:1

• Re-read README.md hoping that requirement to inject scripts in this way is documented somewhere
• Relax CSP headers to allow unsafe-inline
• Vue devtools start working

What is expected?

• Dev tools should operate without having to compromise on site security by allowing inline scripts
• If this isn't technically possible, this incompatibility should be documented clearly in the README

What is actually happening?

• Dev tools cannot detect running Vue instance

[Akryum]

The devtools can't communicate with the webpage without injecting a script.

[lol768]

Does it have to be inline? Can you reference a moz-extension script, or one that's externally hosted?

[chearon]

There's at least one extension developer who's gotten around CSP. This was a hard error to figure out for me, and disabling CSP locally isn't really ideal either. I haven't looked at how the extension communicates with Vue yet, but there might be a way...

[chearon]

Been playing around a bit with this and I've found a few ways to get the dev tools working with CSP enabled. The first two solutions require changes to vue-devtools:

1. In hook.js and detector.js where the <script> elements are created, if it did a setAttribute('nonce', 'vue') then for dev mode people could add 'nonce-vue' to script-src. This would leave CSP on for everything else so you can still catch stray script tags before going on production huh, actually I think this issue is Firefox-only
2. Firefox actually lets you evaluate stuff on the main window using window.eval(), so for that browser you could skip the createElement('script') entirely.
3. If neither of these got merged or for those who need a solution now, you can just add the intializing code into to your development build. The function in hook.js goes before require('vue'), then add window.postMessage({devtoolsEnabled: true, vueDetected: true}, '*') right after. I might release an NPM module to make it easier.

Would a PR for 1 and 2 be accepted?

[lol768]

Hey @chearon!

Appreciate you taking the time to look into this.

There's at least one extension developer who's gotten around CSP

Admittedly this is a creative solution, but I wouldn't say it's the nicest fix I've ever seen 😉

if it did a setAttribute('nonce', 'vue') then for dev mode people could add 'nonce-vue' to script-src. This would leave CSP on for everything else so you can still catch stray script tags before going on production

This isn't a bad approach. My only worry would be people leaving this on in production (and then it becomes a neat way for you to bypass CSP for your XSS payload!) -let's be honest, at least one person would probably do this so it feels too much like giving developers a shotgun to blow their own feet off with.

Firefox actually lets you evaluate stuff on the main window using window.eval(), so for that browser you could skip the createElement('script') entirely.

Interesting, and it seems like in Chrome the extensions aren't impacted by CSP either (which is in-line with how I'd expect extensions to be treated by the browser). This could be a nice workaround for Firefox.

If neither of these got merged or for those who need a solution now, you can just add the intializing code into to your development build. The function in hook.js goes before require('vue'), then add window.postMessage({devtoolsEnabled: true, vueDetected: true}, '*') right after. I might release an NPM module to make it easier.

Honestly, I don't understand why this wasn't the approach taken from the beginning: two separate builds, one dev build with the dev tools initialization code in and one prod build without it. Am I missing something obvious which would have prevented this from working? Why is injecting scripts into the page preferable? I'm pretty sure React took the same approach and I really don't understand why.

I can't see that this would cause problems if the dev tools weren't there, it'd just be a message sent into the aether.

[chearon]

I think the post I linked to was solving something a little different actually.

Interesting, and it seems like in Chrome the extensions aren't impacted by CSP either

Yep. So this issue is entirely a Firefox compatibility thing (see #621 which fixes it, I've been using it).

Honestly, I don't understand why this wasn't the approach taken from the beginning...Why is injecting scripts into the page preferable

I dunno, maybe a Vue team member can answer that. It does seem cleaner to have the initialize code inside a dev build; it wouldn't have to detect Vue by checking every element after X seconds. All browsers do support content scripts behind CSP in one way or another though.

[Akryum]

I think this is to support Vue.config.devtools = true. And also not to increase the size of the library in production.

[michalsnik]

Hey, as I wrote in #621 I don't think we can go around unsafe-inline with eval, because it would violate unsafe-eval option in CSP directive. The nonce that isn't automatically regenerated on each request totally introduces security vulnerability too.

I see two possible solutions:

• Whitelist specific hash in CSP directives , it's unique for each string, and it's impossible to trick it, as any modification in source code (even white space) will result in different sha calculation. More informations here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src
• Don't use CSP header in dev environment, but on staging/production, where it actually matters