To fix the issue you have to add `https://localhost:5000` host-source to the script-src directive. Alternatively you can use syntax 'https://localhost:*' to allow any ports.
To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header. (Sometimes you may see mentions of the X-Content-Security-Policy header, but that's an older version and you don't need to specify it anymore.)
To edit the configuration, go to chrome://extensions and click Options under Content Security Policy Override. The text area in the Options automatically saves as you edit.
What does blocked:csp mean? You may be seeing blocked:csp in Chrome developer tools when the browser is trying to load a resource. It might show up in the status column as (blocked:csp) CSP stands for Content Security Policy, and it is a browser security mechanism.
The self answer given by MagngooSasa did the trick, but for anyone else trying to understand the answer, here are a few bit more details:
When developing Cordova apps with Visual Studio, I tried to import a remote JavaScript file [located here http://Guess.What.com/MyScript.js], but I have the error mentioned in the title.
Here is the meta tag before, in the index.html file of the project:
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *">
Here is the corrected meta tag, to allow importing a remote script:
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *;**script-src 'self' http://onlineerp.solution.quebec 'unsafe-inline' 'unsafe-eval';** ">
And no more error!
It was solved with:
script-src 'self' http://xxxx 'unsafe-inline' 'unsafe-eval';
For anyone looking for a complete explanation, I recommend you to take a look at Content Security Policy: https://www.html5rocks.com/en/tutorials/security/content-security-policy/.
"Code from https://mybank.com should only have access to https://mybank.com’s data, and https://evil.example.com should certainly never be allowed access. Each origin is kept isolated from the rest of the web"
XSS attacks are based on the browser's inability to distinguish your app's code from code downloaded from another website. So you must whitelist the content origins that you consider safe to download content from, using the Content-Security-Policy
HTTP header.
This policy is described using a series of policy directives, each of which describes the policy for a certain resource type or policy area. Your policy should include a default-src policy directive, which is a fallback for other resource types when they don't have policies of their own.
So, if you modify your tag to:
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; media-src *;**script-src 'self' http://onlineerp.solution.quebec 'unsafe-inline' 'unsafe-eval';** ">
You are saying that you are authorizing the execution of JavaScript code (script-src
)
from the origins 'self'
, http://onlineerp.solution.quebec
, 'unsafe-inline'
, 'unsafe-eval'
.
I guess that the first two are perfectly valid for your use case, I am a bit unsure about the other ones. 'unsafe-line'
and 'unsafe-eval'
pose a security problem, so you should not be using them unless you have a very specific need for them:
"If eval and its text-to-JavaScript brethren are completely essential to your application, you can enable them by adding 'unsafe-eval' as an allowed source in a script-src directive. But, again, please don’t. Banning the ability to execute strings makes it much more difficult for an attacker to execute unauthorized code on your site." (Mike West, Google)
The previous answers did not fix my issue, because they don't include blob: data: gap:
keywords at the same time; so here is a string that does:
<meta http-equiv="Content-Security-Policy" content="default-src * self blob: data: gap:; style-src * self 'unsafe-inline' blob: data: gap:; script-src * 'self' 'unsafe-eval' 'unsafe-inline' blob: data: gap:; object-src * 'self' blob: data: gap:; img-src * self 'unsafe-inline' blob: data: gap:; connect-src self * 'unsafe-inline' blob: data: gap:; frame-src * self blob: data: gap:;">
Warning: This exposes the document to many exploits. Be sure to prevent users from executing code in the console or to be in a closed environment like a Cordova application.
We used this:
<meta http-equiv="Content-Security-Policy" content="default-src gap://ready file://* *; style-src 'self' http://* https://* 'unsafe-inline'; script-src 'self' http://* https://* 'unsafe-inline' 'unsafe-eval'">
To elaborate some more on this, adding
script-src 'self' http://somedomain 'unsafe-inline' 'unsafe-eval';
to the meta tag like so,
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 'self' 'unsafe-inline'; script-src 'self' https://somedomain.com/ 'unsafe-inline' 'unsafe-eval'; media-src *">
fixes the error.
Adding the meta tag to ignore this policy was not helping us, because our webserver was injecting the Content-Security-Policy
header in the response.
In our case we are using Ngnix as the web server for a Tomcat 9 Java-based application. From the web server, it is directing the browser not to allow inline scripts
, so for a temporary testing we have turned off Content-Security-Policy
by commenting.
How to turn it off in ngnix
By default, ngnix ssl.conf file will have this adding a header to the response:
#> grep 'Content-Security' -ir /etc/nginx/global/ssl.conf add_header Content-Security-Policy "default-src 'none'; frame-ancestors 'none'; script-src 'self'; img-src 'self'; style-src 'self'; base-uri 'self'; form-action 'self';";
If you just comment this line and restart ngnix, it should not be adding the header to the response.
If you are concerned about security or in production please do not follow this, use these steps as only for testing purpose and moving on.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With