1

I am trying to setup the CSP and Ember is doing something funny, difficult to describe what. I am rightly configuring one part, and it is failing in another part. Or suddenly, livereload is blocked. Or it says that script-src is not defined, and falls back to default-src, which is fine, if it weren't a lie. I know ember-cli-content-security-policy is processing the CSP to allow for livereload and whatnot, but I do not know when/how this is done. I want to verify that the CSP I configure is surviving ember-cli processing, because after one hour of debugging I do not trust it anymore.

Long story short: I want to see the CSP at startup of my app, right when the versions are shown. I do not want to see the CSP that I have configured, but the one that Ember is using, which might or might not be the same: this is exactly what I want to find out.

How can I tell Ember "show me the CSP that you are using"?

EDIT

Thanks to @Bek for the tip about checking the request headers.

With this config (copy-pasted from the ember-cli-content-security-policy readme):

ENV.contentSecurityPolicy = {
  'default-src': "'none'",
  'script-src': ["'self'", "https://cdn.mxpnl.com"], // Allow scripts from https://cdn.mxpnl.com
  'font-src': ["'self'", "http://fonts.gstatic.com"], // Allow fonts to be loaded from http://fonts.gstatic.com
  'connect-src': ["'self'", "https://api.mixpanel.com", "http://custom-api.local"], // Allow data (ajax/websocket) from api.mixpanel.com and custom-api.local
  'img-src': "'self'",
  'style-src': ["'self'", "'unsafe-inline'", "http://fonts.googleapis.com"], // Allow inline styles and loaded CSS from http://fonts.googleapis.com
  'media-src': null // `media-src` will be omitted from policy, browser will fallback to default-src for media resources.
}

I get these headers:

Content-Security-Policy-Report-Only: default-src 'none'; script-src 'self',https://cdn.mxpnl.com,e,l,f,', ,',u,n,s,a,f,e,-,e,v,a,l,' localhost:49152 0.0.0.0:49152; font-src 'self',http://fonts.gstatic.com,e,l,f,'; connect-src 'self',https://api.mixpanel.com,http://custom-api.local,l,f,' ws://localhost:49152 ws://0.0.0.0:49152 http://undefined:16013/csp-report; img-src 'self'; style-src 'self','unsafe-inline',http://fonts.googleapis.com,l,f,'; media-src null; report-uri http://undefined:16013/csp-report;

It seems that indeed ember-cli-content-security-policy is doing something funny. No idea how to solve that. I have opened an issue.

blueFast
  • 41,341
  • 63
  • 198
  • 344
  • you want to display `contentSecurityPolicy` hash from environment.js ? – Bek Jan 01 '16 at 09:56
  • @Bek: no, I know what that is, since I set it myself. I want to display the `contentSecurityPolicy` that the live ember app is using. Once the app starts. Right before any requests (except the one loading the app, of course), are sent. – blueFast Jan 01 '16 at 09:58
  • it is confusing, I thought it is what ember using `contentSecurityPolicy` from environment.js – Bek Jan 01 '16 at 10:04
  • you always have option removing addon if it is disturbing the development :P – Bek Jan 01 '16 at 10:05
  • `ember-cli` builds on top of the `contentSecurityPolicy` you set in `environment.js`. In theory, what it does is minimally invasive but since, as described in the question, "it is doing something funny" for me, I want to know what the real (after processing) `contentSecurityPolicy` is, to understand what is going on. – blueFast Jan 01 '16 at 10:12
  • @bek: removing it is not an option. I had it removed, but once I move to production, I realize that I need it (the default browser settings are too restrictive?): my API server can not be contacted, and my Amazon S3 assets are not loaded. – blueFast Jan 01 '16 at 10:14
  • @gonvald CSP is simple header (attached to all requests) sent from your host server, you can always can check it going to chrome dev tools networks section – Bek Jan 01 '16 at 10:25
  • @gonvald cool thanks ! – Bek Jan 01 '16 at 10:35

1 Answers1

2

Content Security Policy is simple header (attached to all responces) sent from your host server, you can always check it going to chrome dev tools networks section

I get these headers:
It seems that indeed ember-cli-content-security-policy is doing something funny. No idea how to solve that. I have opened an issue.

This issue is in v0.4.0 but not in master (I guess it was fixed) so for now you can install it from master

"ember-cli-content-security-policy": "rwjblue/ember-cli-content-security-policy#master",
Bek
  • 3,157
  • 1
  • 17
  • 28
  • Thanks Bek. It seems that `ember-cli-content-security-policy` is doing something strange. I have editted my answer to describe what I found out. Do you have an idea of what could be going on? – blueFast Jan 01 '16 at 10:46
  • Great, thanks! I wonder why I didn't see this before. I am sure I had csp@0.4.0 installed last week, and then I removed it to stop it from getting in my development cycle. Yesterday, when deploying to production, I reinstalled with npm, to allow access to external API and Amazon S3. It could be that the 0.4.0 in npmjs has changed recently, introducing a bug. That would mean version 0.4.0 has been **overwritten**, and that is something to really frown at. – blueFast Jan 01 '16 at 11:23
  • @gonvaled I don't think they changed 0.4.0, if they did change code they would increment version number, otherwise it would lead to disasters :), but I think you just didn't notice the bug before – Bek Jan 01 '16 at 11:28
  • could be that I somehow missed this, or that my setup has changed during this last week. What I have changed for sure is to add an explicit `ENV.contentSecurityPolicy` in my `environment.js`, and maybe that is what's triggering the error. On the other hand: this is not the first time that I experience versions on npmjs overwritten. And another remark: I really doubt that 0.4.0 can survive a long time in npmjs without triggering this bug for lots of people, and the fact that this issue was (as it seems) undetected, makes me think that npmjs has indeed been overwritten recently. – blueFast Jan 01 '16 at 11:34
  • even if it is overwritten in npm i does not mean that I can break, as main repo version was not changed. There is thing called `npm shrinkwrap` that locks down source of package if you want to be really careful – Bek Jan 01 '16 at 11:37