A single content security policy error appears in browser console on load

[epixa]

IMPORTANT

It is expected for you to see the following error and then console output in your browser, it does not allude to a bug:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'unsafe-eval' 'nonce-RVRtUDr0ivQi+9ju'". Either the 'unsafe-inline' keyword, a hash ('sha256-SHHSeLc0bp6xt4BoVVyUy+3IbVqp3ujLaR+s+kSP5UI='), or a nonce ('nonce-...') is required to enable inline execution.
^ A single error about an inline script not firing due to content security policy is expected!

Kibana version: 6.7.0+

Browser version: All modern browsers

Describe the bug:

When you load Kibana, an error is logged to the browser dev console due to an inline script being rejected due to the content security policy. The error message itself varies between Firefox, Chrome, and Safari.

This is the result of our CSP check that verifies whether the browser is enforcing the security policy before bootstrapping Kibana. We literally inject an inline script and then verify that it was blocked. Unfortunately, it doesn't seem possible to catch the error in this scenario since it's not really JavaScript itself that is triggering it.

At this point the behavior is expected, but it's not ideal. If we could somehow do an inline script check without triggering an error in console, we should switch to that mechanism. Otherwise, when we get rid of unsafe-eval in our CSP, we should be able to get rid of this console error by switching to an eval-based check, which should be something we can catch.

[elasticmachine]

Pinging @elastic/kibana-security

[LeeDr]

The text is (as seen in IE11 on 7.0.0);
Your browser does not meet the security requirements for Kibana.

Should there be a link to release notes, or some kind of doc about it?

[joej]

Graph also -- Content Security Policy directive: "script-src 'unsafe-eval' 'self'" issues prevent saving of most Kibana items.

[kobelb]

@joej are you having an issue using the Graph application because of the enforced content security policy? If so, the problem that you're experiencing is different than the one that this issue is tracking, and opening up a new bug report would be appreciated.

[joej]

6.7.0 and 6.7.1 kibana seems to fail at ALL saves -- from graph, from viz, from discover.
Firefox and Chrome do it.

there is a ticket open at support.elastic.co

[ch-bas]

A workaround will be to add the hash code that you see in the console, to this file 'src/server/csp/index.ts' , as a parameter for the object.freeze and the error should disappear.

[kobelb]

A workaround will be to add the hash code that you see in the console, to this file 'src/server/csp/index.ts' , as a parameter for the object.freeze and the error should disappear.

@ch-bas I'm not sure I'm following, would you mind elaborating?

[ch-bas]

When the error is logged to the browser, there is a hash code generated:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'unsafe-eval' 'self'". Either the 'unsafe-inline' keyword, a hash ('hash code here' ).....

If you copy and past that hash code to the file 'kibana/src/server/csp/index.ts'
export const DEFAULT_CSP_RULES = Object.freeze([ script-src 'unsafe-eval' 'self' 'hash code here']
then the console error will disappear.

[Susmit07]

@epixa @kobelb what is the solution, as still I am facing the same issue, and it's a serious production issue which needs to be addressed

[kobelb]

@Susmit07 is your issue that we're triggering a CSP violation error on start-up and displaying a warning? I don't see how this could be considered a serious production issue, if you could please elaborate.

Or are you experiencing an issue by our enforced CSP policy? If so, this can be customized using csp.rules in your kibana.yml. However, if this is the case, I'm quite interested in your reasoning for adjusting the default CSP rules. Are you relying upon a third-party plugin which is violating the policy? Or is the lack of support for Edge your primary concern?

[Susmit07]

@kobelb I think I am experiencing an issue due to enforced CSP policy. Shall be grateful if you can let me know what I need to add in the kibana.yml file for bypassing csp violation. I am not using third party plugin, and I am using Chrome, Mozilla & Safari to check. Pls. find below the screenshot. The error is coming at the start up itself

https://user-images.githubusercontent.com/32009785/59678858-152b1d80-91eb-11e9-9563-9af916eca08e.PNG

[kobelb]

Hey @Susmit07, that screenshot that you've posted shows things working as expected. When Kibana first loads, we intentionally violate the enforced CSP policy to determine whether or nor you're using a legacy browser and display an appropriate warning.

You can safely ignore that console error. That's what the console line right below it is trying to explain.

Are you getting stuck on the "Loading Kibana" screen, or is there something else that is broken? If so, we're likely dealing with a different issue. If you could elaborate on the behavior you're seeing, I can do my best to confirm.

[Susmit07]

Thank you @kobelb. Actually I am trying to access kibana portal from outside the VM in which actually the Elastic and Kibana instances are running. Whenever I am trying to access the Elastic port it is working fine, and showing me the desired details along with the version. But when I tried to access port 5601 for Kibana I am not able to access the same, but I am able to access within the same local machine. I am getting the error mentioned below :

Kibana did not load properly. Check the server output for more information

I checked in the server output but there were no errors actually printed

I am using server.host = 0.0.0.0, and its a Windows VM where the ELK stack is actually running

[kobelb]

@Susmit07 to figure out the root cause of your issue, this is going to require some debugging. Would you mind creating a topic over in our discuss forums and capturing a HAR of the network traffic from your browser, in addition to the logs from your Kibana instance after setting logging.verbose: true in your kibana.yml to help us get started diagnosis the issue?

[Susmit07]

It's already there
https://discuss.elastic.co/t/kibana-did-not-load-properly-check-the-server-output-for-more-information-kibana-not-working/186224

[vchauhan81]

@Susmit07 to figure out the root cause of your issue, this is going to require some debugging. Would you mind creating a topic over in our discuss forums and capturing a HAR of the network traffic from your browser, in addition to the logs from your Kibana instance after setting logging.verbose: true in your kibana.yml to help us get started diagnosis the issue?

Hi,
Please refer to the debug logs and the error screen shot.

logs.txt

[kobelb]

@vchauhan81 please create a discuss topic as well. We don't use GitHub to debug issues like these, it's for known bugs/feature-requests/etc.

[vrajroutu]

Same issue was identified Kibana (7.0.0 )

[LeeDr]

I am using server.host = 0.0.0.0, and its a Windows VM where the ELK stack is actually running

@Susmit07 I don't think you can use server.host = 0.0.0.0 on Windows. I think you have to use the IP of the VM itself. That's what I've always done.
I can use server.host = 0.0.0.0 on Linux platforms.

[jeramysoucy]

Closing this issue for now. We've investigated ways in which we could check that CSP is supported by a browser, but there is no effective way to do this without a resulting visible console error message or error issue indication. Firefox will always log CSP violations to the browser console, even when we attempt to intercept and stop 'securitypolicyviolation' events. Though we can suppress the browser console message in Chrome, it will always add an error issue for any CSP violation in the Console tab of dev tools.

Currently, there is no other deterministic way of discerning if CSP is supported by a browser other than to trigger a violation. Additionally, browser response to CSP is not standardized, further complicating any resolution to this issue.

cc: @legrego