I'm loading a dummy JS script from origin like:
<script src="http://www.this-host.test/loadMe.js"></script>
with CSP header set to:
script-src 'self' 'strict-dynamic' 'nonce-{randomString}';
Since the script source is comming from it's origin host and is allowed by CSP header than loadMe.js should load and execute.
Instead I get:
Refused to load the script 'http://www.this-host.test/loadMe.js' because it
violates the following Content Security Policy directive: "script-src 'self' 'strict-dynamic' 'nonce-{randomString}';.
'strict-dynamic' is present, so host-based whitelisting is disabled.
tested on Macintosh; Mac OS X 10_15_2, browsers Chrome/79.0.3945.117, Firefox/71.0.
I don't get this message on Safari though.
Perhaps good to note that I'm testing it locally.
Anyway I don't want to use nonce-{randomString} when CSP header allows resources to be loaded from origin host.
Any thoughts on that?
According to csplite.com server with CSP header script-src 'self' 'strict-dynamic' 'nonce-{randomString}' set...
'strict-dynamic' only works in conjunction with 'hash-value' or 'nonce-value', and if they are absent, all scripts on the page will be disabled, because 'strict-dynamic' overrides the 'unsafe-inline' action and disables whitelisting of host-based sources, including the 'self' token
... which tells me that If my loadMe.js file is loading another file (or it doesn't have to) nonce="{randomString}" attribute in HTML tag must be set no matter if the file is loaded from same host or whitelisted host.
Related
I have a certain internal js-file which I want to block with the use of the Content Security Policy.
I know it's possible to disable external files, but I didn't found informations regarding a certain internal script.
At the moment I use the following CSP:
img-src 'self' data:; default-src 'self' 'unsafe-inline'
So I'm searching a solution to make an exception for default-src 'self'.
If you don't want to allow scripts from 'self', you will need to remove 'self' from default-src and implement all the needed source directives that currently use default-src as a fallback. If you set default-src to 'none' or the remaining value of 'unsafe-inline' the browser errors will tell you what you need to add.
#console browser issue for Content security Policy
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-9X08/o2ns8hEbTzT0V1Xyn6yYc8qftFOKmH3KNb8dWo='), or a nonce ('nonce-...') is required to enable inline execution.[enter image description here][1]
#Image of the error
[1]: https://i.stack.imgur.com/7R9sp.png
Code written for CSP
frame-ancestors 'self' https:
script-src 'self';
object-src 'none';
base-uri 'none';
style-src 'self' fonts.googleapis.com 'unsafe-inline';
media-src *;
img-src 'self';
It seems the error indicated there's issue with using inline-script.
which looks like
<script>
your codes
</script>
If you're going to use inline script, add 'unsafe-line' to script-src directive.
Current setting only allows scripts that's source of your domain.
ex)
<script src="/yourDomain/public/yourScript.js">
Your script-src directive of 'self' only allows scripts to be loaded as script files from the same domain. Your page also has inline scripts that need to have permission in the CSP to run. You have a few choices:
Move the script code to a separate .js file hosted on the same domain. If you use a different host you'll need to allow that host in your script-src directive.
Add 'unsafe-inline'. This will allow ALL inline scripts, which will pretty much remove the XSS protection that CSP is able to give.
Add the suggested hash value 'sha256-9X08/o2ns8hEbTzT0V1Xyn6yYc8qftFOKmH3KNb8dWo=' to script-src allowing this one script. This is a good solution if there are only one or a few inline scripts to allow.
Add a nonce. Nonces should change on every pageload and are a good solution for dynamic scripts if you are able to inject nonces correctly.
I have currently an issue with a SharePoint web application, where all websites return a response header content-security-policy: default-src 'self'; object-src 'none'; form-action 'self', which breaks the website's view using Chrome or Firefox, as styles won't be applied and Javascript won't be executed.
Console-Log
Refused to execute inline script because it violates the following Content Security Policy directive: default-src 'self'.
Either the 'unsafe-inline' keyword, a hash ('sha256-WFRyoBrQbrYtLpGIdyBszDzxQni3b0V/wUirab0OhKM='), or a nonce ('nonce-...') is required to enable inline execution.
Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
The problems only occurs if the websites are addressed using HTTPS. I already checked the HTTP Response Headers in IIS. content-security-policy is not specified. If I add it myself, it gets overwritten and is not sent in the response header. There are only two solutions installed, which do not mess with the response headers.
Has anyone an idea what else could change the custom response header and overwrite the one defined in the web.config? Or is there an other way to change the Content-Security-Policy?
I tested changing the IIS Response Headers by configuring the "CustomHeaders"-section in the web.config, by writing custom IIS modules, which modified the headers using the request lifecycle, and also by writing additional rules with the URL Rewriting tool. Nothing worked...
In the end we found out someone extended the firewall, which onwards would add new header and overwrite my changes of the HTTPS response. Mystery solved :)
In my case, I was asked by Network and Information Security Team to add the Content-Security-Policy: default-src 'self'; header in my IIS 8.5 SharePoint Server 2016 Publishing website which affects all the system pages and the browser refuses to execute the scripts and in console we got this error
Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-HU8dCwZsqh4m8QG0y6qanyzPx1d6YSGHuAN0QXmxZvw='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
I then change the header to Content-Security-Policy:frame-ancestors 'self'; and it resolves the issue.
I actually got this from the JohnC's Answer that helps me resolving the issue
For some reason both Mozilla Observatory and CSP validator are not detecting the CSP header in my .htaccess file yet the header is visible when viewed through Chrome.
Here's my current CSP header in my .htaccess file;
Content-Security-Policy: script-src 'nonce-$RANDOM' 'strict-dynamic' 'unsafe-inline' object-src 'none'; base-uri 'none'; report-uri https://altfit.report-uri.com/r/d/csp/enforce;
Also I noticed that the nonce is not working, inline scripts still load without nonce in place but if I make modifications to the CSP it can restrict script execution and the display of inline elements.
Info:
Server is Light Speed.
PHP version is 7.1
Fixed the issue by modifying the line in .htaccess to the following;
Header set Content-Security-Policy: "default-src https: 'unsafe-inline'; report-uri https://altfitcom.report-uri.com/r/d/csp/enforce;"
Only issue now is the addition of unsafe-inline but from what I have read strict-dynamic and nonce do not work as a cross platform solution and I have to have inline js for some onclick events.
I started exploring Content Security Policy on a website which uses inline scripts and other crimes. I configured CSP per header field like this:
content-security-policy: default-src *; frame-ancestors 'self'; style-src 'self' 'unsafe-inline' fonts.googleapis.com cdn.jsdelivr.net *.stripe.com; report-uri https://sentry.io/api/x/csp-report/?sentry_key=y
My problem now is that the browser complains with the following message:
Refused to execute inline script because it violates the following Content Security Policy directive: "default-src *"
I read the documentation for default-src <source> which states that <source> can be one of the following sources:
<host-source>
<scheme-source>
'self'
'unsafe-inline'
etc.
It seems to me that the asterisk can only be used for host sources. But what else can I do since only one <source> seems to be allowed? default-src * 'unsafe-inline' would not be compliant, right?
My goal basically is to use a minimal CSP configuration which works (and can be embedded via iframe). I am aware that it's best practice to go on with specific rules.
It seems to me that the asterisk can only be used for host sources.
Yes
But what else can I do since only one <source> seems to be allowed?
Multiple <source>s are allowed.
default-src * 'unsafe-inline' would not be compliant, right?
It’s compliant.
You can use https://cspvalidator.org/ to check. Or https://csp-evaluator.withgoogle.com/.
But you really want to avoid specifying 'unsafe-inline' in any CSP policy. Using 'unsafe-inline' pretty much defeats the entire purpose of CSP.
What you want to do instead for any inline scripts causing CSP errors is: take the scripts out of your document and move them into separate files. That’s sort of the whole point.
But if you really must specify 'unsafe-inline', then as far as the dealing with the specific error cited in the question, you should only specify 'unsafe-inline' for script-src — because the error message says, “Refused to execute inline script.”
If you instead specify 'unsafe-inline' for default-src, then that causes the browser to fail to do CSP checks for any inline resources in your document — stylesheets, etc., too, not just scripts.
So if the only problem is an inline script and for some reason you can’t fix that by moving the script out to a separate file, or specifying a hash or nonce for it, then you should at least only specify 'unsafe-inline' for script-src.