Curious (and hard to diagnose) issue. I've added a CSP to my site, and it is working just fine, with 1 error which seems to only appear on Firefox (guessing it is a Mozilla CSP implementation anomaly). I'm not really sure, however, how to even really dig deeper into diagnosing this at this point. It does not appear to be hindering any functionality - everything seems to work, but I see the error popping on Firefox (and its reporting is quite spammy, which I could deal with in other ways, but would rather root cause and handle).
Here's the error (which appears on virtually every single page of the site):
Content Security Policy: The page’s settings blocked the loading of a resource
at self (“script-src https://code.jquery.com/”). Source: ;(function
installGlobalHook(window) { ....
I typically load jQuery via CDN, and have no problems with it loading and running, though I did try also downloading the jQuery and loading it internally (which also worked fine).
The full CSP is:
Content-Security-Policy:
default-src 'self';
base-uri 'self';
script-src 'self' https://code.jquery.com/;
form-action 'self';
font-src 'self' https://fonts.googleapis.com/ https://fonts.gstatic.com/;
style-src 'self' https://fonts.googleapis.com/
https://code.jquery.com/
'sha256N90MKmRow2DpYEVeqcc3uc8pOUsS4Rg4sNmkau1k0xQ='
'sha256-i1EfB2+xYUUG32uDRMNI/DN/F9YIrGWOYdHENz9GKME='
'sha256-75seZ0liXI7HbegtdV/WH+/9QQJ0CrDacBOViVFXckc='
'sha256-2KAnfZnKiF2um1+UfXP14UfR93HoXmam2Y1ipeMWRUI=';
frame-ancestors 'self';
report-uri /csp/csp-report
Just re-verified, only seeing the error on Firefox. I've reviewed other related issues, but nothing seems to address this issue directly (ex: CSP Violation Detected in Firefox OS validator).
Also, I'm noting the error appears in the console immediately after the page GET, but before all of the resource GETs (for scripts, css files, etc.), so I'm wondering (even more) if it could be a FF bug with CSP...?
Any thoughts or suggestions about how to proceed from this point would be very helpful - I've kind of run myself out of leads. Thanks!
** UPDATE ** - Ug. It is definitely React DevTools Firefox extension. Disable the extension, CSP violation goes away. Also, because this is a component of the extension itself, no way to use React DevTools with FireFox + CSP (with any level of security actually turned on). Blagh.
Solved this in a relatively sub-optimal way (IMHO).
Firefox apparently isn't a big fan of CSP's "default-src" attribute being set to 'self', as I had it in my config. Changing the "default-src" directive to my actual host source ('localhost' for dev and the actual domain 'https://*.foobar.com' for prod), the CSP violation for installGlobalHook(window) ceased.
FYI in case anyone else runs across this error...
Related
I am working with firefox version 84.0.2 . I am creating a node web application hosted at https://parent.example.com which is configured to return response header as : Content-Security-Policy: frame-src https://child.example.com .
But I am able to open URLs in iframe other than https://child.example.com from https://parent.example.com in firefox.
But as the header suggest it should get blocked. The same thing is working fine in chrome.
I made a couple of research and found out that there is confusion between CSP:frame-src and CSP:child-src . and somewhere it was suggested to use both headers. (ref: How to use frame-src and child-src in Firefox and other browsers? and ).
Therefore, I added both the directives as: Content-Security-Policy: frame-src https://child.example.com; child-src https://child.example.com
But still, I get no success. So, could anyone let me know how to let things work in firefox ?
You have in Firefox some plugin installed which affects CSP header.
Because Firefox 84 definitely blocks any iframes not allowed in the frame-src directive.
Could you show me your HTML where frame-src does not work as intended?
Is there a secure way of whitelisting dynamically created scripts in a WebForms project using CSP (Content Security Policy)?
Using unsafe-inline like below it works but not recommended.
context.Response.Headers.Append("Content-Security-Policy", string.Format("default-src 'none'; connect-src 'self'; font-src 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self' 'unsafe-inline'"));
For any other options such as nonce-(random), we see this CSP error message:
Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src 'self'". Either the
'unsafe-inline' keyword, a hash, or a nonce is required to enable
inline execution.
There is no such thing as 'safe-inline' for dynamic scripts, try to use dynamic imports instead? (you can reload such script in code)..
You shouldn't normally have to use 'unsafe-inline', two things that often becomes problematic is the live-reloading in development and setTimeout/setInterval in your code, they can trigger CSP easily. So better to just disable CSP in development to increase your delivery speed. 'unsafe-inline' is to enable execution of dynamically created scripts.
Update
To solve this you need to load a custom script using the standard (perhaps with async/defer) <script src="/myscript.js"></script> and 'unsafe-inline' requirement goes away. However, your technology choice ("webforms") might limit your options to do that. To test anyway, use a cdn url or a separate server (internal or external) to deliver your script. I have tested this locally with nodejs and it works as expected. The "problem" you have is most likely because that you write code like this (or code is put there):
<script>function unsafeInline() { ... }</script>
Modernizr is now v3.6.0 you use v2.8.3 and to make your error go away you can add this to your header:
<header>
<title>CSP Test</title>
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://cdnjs.cloudflare.com/;">
<script src="https://cdnjs.cloudflare.com/ajax/libs/modernizr/2.8.3/modernizr.min.js"></script>
</header>
From a related SO question:
If modernizr is injecting all that inline stuff than it seems like your choices are to either (a) add all those hashes, (b) use 'unsafe-inline' (but which basically defeats the whole purpose of CSP…), or (c) don’t use modernizr.
The answer to that question is: remove "inline stuff" from modernizr. You can always use document.body.style = "background: #000000;"; from an external library to set style (or other) attributes. I tried all "normal" code activities in an imported external script and it doesn't trigger CSP. By normal I also mean assign objects (functions) to the window object and executing them.
Look for *.createElement("script") or similar, since that will for sure trigger CSP.
I pasted the googletag manager code in my joomla website, But it showing following error in console. and also not reflection in the google dashboard
Refused to load the script 'https://www.googletagmanager.com/gtm.js?id=GTM-T44GGZR' because it violates the following Content Security Policy directive: "default-src 'self' 'unsafe-inline' 'unsafe-eval' data: *.googleapis.com *.gstatic.com *.google-analytics.com *.youtube.com *.g.doubleclick.net https://s.ytimg.com/yts/jsbin/ *.googleadservices.com *.google.com *.google.cz http://platform.linkedin.com cdnjs.cloudflare.com static.hotjar.com widget.prodpad.com api-widget.prodpad.com vars.hotjar.com script.hotjar.com insights.hotjar.com wss://ws4.hotjar.com www.google.com.pk wss://ws1.hotjar.com wss://ws5.hotjar.com https://www.transguardgroup.com". Note that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
Google Tag Manager is a script injector (and actually it injects itself via a few lines of bootstrap code), so it will not work with unsafe-inline in place.
Simo Ahava has an article about configuring your CSP for GTM, but that basically removes the protection your CSP is supposed to offer, so you have to choose between the convenience of GTM or the security via a CSP.
I recently added the following CSP policies for https://stefan.sofa-rockers.org/
default-src 'self'; style-src 'self' https://brick.a.ssl.fastly.net; font-src 'self' https://brick.a.ssl.fastly.net
It seems to work well on all browser, but Firefox is showing me this strange, truncated error message:
Content Security Policy: The page’s settings blocked the loading of a resource at self (“default-src https://stefan.sofa-rockers.org”). Source: (function (ERROR) {
const V8_STACK_.... stefan.sofa-rockers.org:1
Do I have an error in my CSP (all resources are getting loaded, so I don't think this is the case) or might this be a bug in Firefox itself?
It looks like you may be hitting a known Firefox bug that’s been partially fixed in Firefox 58. See the Improved Content Security Policy (CSP) Handling section of the following blog post:
https://blog.mozilla.org/addons/2017/11/20/extensions-in-firefox-58/
The relevant existing Firefox bugs are these:
https://bugzilla.mozilla.org/show_bug.cgi?id=1406278
https://bugzilla.mozilla.org/show_bug.cgi?id=1267027
And specifically, as noted in the comments here, if you have the Privacy Badger add-on installed, you might need to consider disabling it.
See also the following related Stack Overflow answers:
Firefox content script not loading in some pages
Content Security Policy failing on line 1 (Firefox 57.0)
I am using the Prototype JS framework to do Ajax calls. Here is my code:
new Ajax.Request( '/myurl.php', {method: 'post', postBody: 'id='+id+'&v='+foo, onSuccess: success, onFailure: failed} );
function success(ret) {
console.log("success",ret.readyState, ret.status);
}
function failed(ret) {
console.log("failed",ret.readyState, ret.status);
}
Most of the time, this works fine and the success function is called with a status code of 200. About 5% of the time on Safari the success function is called with a status code of 0. In this case, when I look in the Network tab of the web inspector, the ajax call is listed with a status of "canceled". I can confirm with server logs, that the request never hit the server. It's as if the ajax request was immediately canceled without even trying to connect to the server. I have not found any reliable way to reproduce this, it seems to be random. I do it 20 times and it happens once.
Does anyone know what would cause the ajax call to get canceled or return a status code of 0?
The cause may be the combination of http server and browser you are using. It doesn't seems like an error of the PrototypeJS library.
Multiple sources states that keep-alive parameter of the HTTP connection seems to be broken in Safari (see here, here or here). On Apache, they recommend adding this to the configuration:
BrowserMatch "Safari" nokeepalive
(Please check the appropriate syntax in your server documentation).
If Safari handles badly HTTP persistent connections with your server, it may explain what you experiences.
If it's not too complex for you, I would try another HTTP server, there are plenty available on every OS.
We lack a bit of information to answer fully your answer, though. The server issue is a lead but there may be others. It would be nice to know if it does the same thing in other browsers (Firefox with Firebug will display this kind of information, Chrome, Opera and IE have development builtin toolboxes). Another valid question would be how often you execute this AJAX request per second (if relevant).
I know this is an old topic, but I wanted to share a solution for Safari that might save others some time. The following line really solved all problems:
BrowserMatch "^(?=.*Safari)(?=.*Macintosh)(?!.*Chrom).*" nokeepalive gzip-only-text/html
The regex makes sure only Safari on Mac is detected, and not Mobile Safari and Chrome(ium) and such. Safari for Windows is also not matched, but the keepalive problem seems to be a Mac-Safari combination only. In addition, some Safari versions do not handle gzipped css/js well.
All our symptoms of our site crashing or CSS not completley loading in different versions of Safari which caused me to nearly pull my hair out (Safari really is the new IE) have been solved for us with this Apache 'configuration hack'.