Repository navigation
Content Security Policy (CSP) #1672
Description
Activity
I was under the impression that Chrome blocks it because Google was trying to assert its will on other developers to make them code their way. I'm a big fan of good coding practices, but I'm not a fan of having them be forced.
One thing I really like about node-webkit is the flexibility and control it gives me as a developer. If I need to do something a certain way, I can.
In short, I don't have a problem with CSP being enabled by default. I generally don't do things that avoid it being turned off. But the difference between Google Chrome and node-webkit is that in Chrome you as a developer have no power to turn it off.
I'm not suggesting that CSP be enforced, just that it is supported at all. Default or not.
As for Google. There are legitimate reasons to enforce CSP when privileged Apis are exposed as most developers understandably choose the path with the least friction, even if they sacrifice security along the way. It is the platform maker's responsibility to protect its users and good design often requires making the hard choice for others. Firefox Packaged Apps do this as well by the way: https://developer.mozilla.org/en-US/Marketplace/Publishing/Packaged_apps#Types_of_packaged_apps
Any progress on this? I've tested the recent v0.10.1 of node-webkit but CSP is still not possible. Do you guys explicitly deactivate it to get the node apis working or what is the logic behind this?
+1 definitely helps when building node-webkit based apps, and being sure that no XSS will happen when dealing with untrusted content
Joe Marini from the Chrome team confirmed in the JavaScript Jabber Podcast, that Chrome Packaged Apps will soon be deployable without users having Chrome installed, basically packaging the chrome runtime with your app. We will be using this solution instead of node-webkit due to the missing CSP support
Nice.
2014-09-10 23:50 GMT+03:00 Tankred Hase notifications@github.com:
Joe Marini from the Chrome team confirmed in the JavaScript Jabber
Podcast, that Chrome Packaged Apps will soon be deployable without users
having Chrome installed, basically packaging the chrome runtime with your
app. We will be using this solution instead of node-webkit due to the
missing CSP support—
Reply to this email directly or view it on GitHub
#1672 (comment)
.,
Apostolis XekoukoulotakisThe fix can be tested now with:
http://dl.node-webkit.org/live-build/09-11-2014/linux64_master-build-168-4a08e10-692f0ab-3cd3e16-0f7c844-ae5bb86-86728d1/node-webkit-v0.10.5-pre-linux-x64.tar.gz
http://dl.node-webkit.org/live-build/09-11-2014/mac64_master-build-173-4a08e10-692f0ab-3cd3e16-0f7c844-ae5bb86-86728d1/node-webkit-v0.10.5-pre-osx-x64.zip
http://dl.node-webkit.org/live-build/09-11-2014/win64_master-build-176-4a08e10-692f0ab-3cd3e16-0f7c844-ae5bb86-86728d1/node-webkit-v0.10.5-pre-win-ia32.zip@rogerwang Thanks! So does this mean all
normal framesnow automatically have CSP enabled?- added a commit that references this issue
on Sep 25, 2014 - added a commit that references this issue
on Jan 28, 2015
Chrome Packaged Apps have CSP enabled by default to protects users against code injection attacks. In runtimes such as PhoneGap this isn't enabled by default, but developers can set the meta tag in the html document head. Like so:
This blocks inline scripts and other sources and only allows locally loaded scripts. E.g. the following code should not allowed to be executed:
Chrome blocks this code while node-webkit doesn't. Is there a reason for this?
The reason I'm asking is that we are porting our PGP mail client (https://whiteout.io) from chrome packaged apps to node-webkit. But this issue is basically a showstopper for us, as it could allow an attacker to get a hold of the user's private key should he be able to inject code somehow.
Thanks