So I'm trying to avoid using (another) page rule to disable Rocketloader for one of my subdomains, since we can't use a RegEx to select multiple specific subdomains under a single page rule, and only get 3 page rules for free accounts.
According to this page:
https://support.cloudflare.com/hc/en-us/articles/216537517-Using-Content-Security-Policy-CSP-with-Cloudflare
I can just add a header to the domain to allow scripts from CloudFlare:
add_header Content-Security-Policy "script-src 'self' ajax.cloudflare.com;";
I did so in the Nginx config for that subdomain (it's a Chronograph container actually), restarted Nginx, tested to make sure it "took", which it did:
But then when I try to load the domain, it won't load, and the inspector shows this:
Not being super familiar with this, does anyone know where I screwed it up?
where I screwed it up?
First of all, here:
I can just add a header to the domain to allow scripts from CloudFlare:
add_header Content-Security-Policy "script-src 'self' ajax.cloudflare.com;";
I did so in the Nginx config
And secondly, you trusted the report-uri service, but it failed you.
You have had an issue with ajax.cloudflare.com BEFORE adding CSP header into Nginx config (otherwise, why add it). This means that you already have a CSP published via an HTTP header or a meta tag <meta http-equiv= 'Content-Security-Policy'>.
By adding the CSP header to the Nginx configuration, you have added a second policy to the pages.
Multiple CSPs work as sequential filters - all sources must pass through both CSPs to be resolved. The second CSP allows ajax.cloudflare.com host-source, but the first one still prohibits it (that you are observe in the inspector).
You have to figure out where the first CSP is published and to add ajax.cloudflare.com into it, instead of publish second CSP.
No one know what is under the hood of the report-uri and how it will react if two CSP HTTP headers or an HTTP header paired with a meta tag are published simultaneously
Have a look which CSP and how many of them the browser actually gets, the guide is here.
In case of 2 CSP headers you will see something like that:
In case of CSP meta tag you can easily check the by inspecting the HTML code.
I think the report-uri just did not expect such a situation.
Related
If I'm loading another site in an iFrame do the Content Security Policy Headers of that site have any affect on whether the site gets blocked?
e.g. if I open www.google.com in an iFrame is there any interaction between the CSP header settings on my site and the ones on google.com? Or would Google's CSP only affect what they're trying to load in the iFrame.
Of course if google had their own iFrames they'd need CSP headers to allow any 3rd party content to load. But do my CSP headers have any affect on Google's after google.com starts to load? If Google tried to load youtube.com in an iFrame and I didn't include youtube.com in my CSP whitelist would that work?
Sorry if this is a silly question, I'm trying to wrap my head around iFrames. What I'm wondering is if I need to worry about the CSP settings on the third party, especially if I'm nesting iFrames, or if I only need to worry about my CSP policy.
I think what I'm getting at is this: Once I've said "allow this 3rd party site to load" in my CSP headers can that site load whatever it wants based on their CSP headers?
Thanks!
Let's say that you have site A framing site B. Site A must not set a framing policy that denies site B and site B must not set a policy that prevents being framed by A.
Site A can set "frame-src B" to explicitly allow site B to be framed. If frame-src is not set, child-src is used as a fallback, and if that is not set, default-src is used as a fallback. If none of them are restricted, all sites can be framed.
Site B can set "frame-ancestors A" to allow framing by A. This directive has no fallback. If it is not set, any site can frame site B. If it is set, only the sites listed as valid sources can frame it.
Apart for frame-src (child-src, default-src) for the framer and frame-ancestors for the framed, there is no impact on other sites by the CSP, they each control their own sources.
CSP Header directive corresponding to iframes ,
frame-src
frame-ancestors
lets say your site xyz.com and google's site "google.com".
Site xyz.com has its own csp which can controls,
Who can load xyz.com as iframe, decided by frame-ancestors directive
Who can be loaded inside 'xyz.com' as iframe, decided by frame-src directive
same scenario applies for google.com ( whose csp can decide, whom to be loaded as iframe inside its app & whom can load google.com as iframe )
Each html document has its own csp response header, which will not interfere with its host app (parent frame) or its iframes (child frames).
xyz.com 's CSP only decides whom should load it & whom it should load as frame, it cannot control its host frame or child frame ( they are considered as separate entities )
Apart from this another header X-FRAME-OPTIONS is also available with minimal control options to decide whether a site should load as frame or not.
For detailed reference :
CSP - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
X-FRAME-OPTIONS - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
My asp.net project is working fine at our QA machine and deployed at customer end. But when the browse URL, website is not properly displaying. Some alignment issue at customer side any browser. When I clicked F12,It shows error as "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-yP/phO6MWRqPDsL5fwP/+7pIbMUdA+zgVlj8/r2BJDo='), 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."
It seems server side "Content Security Policy" is missing??
Can any one guide me in above issue what need to be done at server side to fix the above issue as it is working fine in our environments like DEV, QA environments.
Thanks in advance
There is a Content Security Policy set on the customer system. This could be a default policy added or an intentional restriction by the customer. You will first need to find where the policy is added and then either remove or modify it or alternatively change your code.
Based on the error messages you'll need to rewrite inline script and inline style into separate files or add "script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'. Note that allowing 'unsafe-inline' is not desired, so your preferred option should be change your code. Noting that violations arise from jquery.min.js it might help to upgrade jquery if the version used is old.
I have a Jira instance running under nginx and we have some CSPs configured in nginx.
Now we are installing an app that generates links that trigger a browser extension, the URLs start with goedit:
The vendor of the app suggests this CSP header:
add_header Content-Security-Policy
default-src https: goedit: wss: 'unsafe-inline' 'unsafe-eval';
img-src https: data: 'unsafe-inline'" always;
I am now trying to incorporate this into our CSP header.
Our CSP Header includes
frame-src '' https://assets.zendesk.com https://www.facebook.com https://$server_name;
When I now click on one of the Links for that app I get this error message in the console:
Refused to frame '' because it violates the following Content Security Policy
directive: "frame-src https://assets.zendesk.com https://www.facebook.com https://my-server.dein-james.de".
I am wondering: What do I need to put into the frame-src to allow this kind of link ('')?
I'd rather not drop the whole frame-src part, I want to keep those whitelisted.
thanks in advance
Jens
I know this is quite an old thread now but I came across a similar issue today. With mine I was using data: in the object-src and I had to ensure data: was then in the frame-src.
Therefore I would check that in frame-src you include any schema's, I suspect it might be the goedit: or wss: in your example?
Though this is old, I found that:
Stefan's solution works.
I had a situation where dynamic iframes (meaning, an iframe added dynamically) were attempting to load a pdf for nice display (in chrome), and though the scp contained "self" for frame-src, and the pdf was from the current domain, some users couldn't see the content, their consoles showed the above error. After messing around, found that simply there is a setting to tweak in the chrome browser - go into the settings, search "pdf" and find the section where you can toggle for pdf the setting that makes pdf's download automatically, vs display in the browser.
I am adding the HTTP Strict Transport Security header to a website.
Does it prevent loading of resources over HTTP that are not in same domain?
HSTS only applies to the domain it's sent with, and any subdomains if the includeSubDomains attribute is also set.
Any other domains are unaffected.
However one thing to be careful of is if your main domain (www.example.com) uses the same config as the bare domain (example.com), which is quite common, and you issue the HSTS header on both (perhaps without realising it's also on the bare domain) and use the includeSubDomains header. If that's the case then you can easily block access to other domains you did not intend to, which are still on http (e.g. http://blog.example.com or http://internal.example.com) if someone visits the bare domain.
BTW if you were wanting to upgrade all the http requests to https you could use Content Security Policy (CSP) which has an upgrade-insecure-requests option. However browser support of that is not yet universal. You can also use CSP to help you identify mixed content as discussed here.
I am new to this thing, so there is some questions I wanted to ask after looking up bunch of site that related to CORS.
First of all, lets say i have http://domain1.com that has a ajax call to http://domain2.com, I look up on http://enable-cors.org/server.html it say that I will have to add
Access-Control-Allow-Origin: *
this response to my page header or add this setting to web.config on the root directory of my application, but I was confused, should I add the response header to domain1 or domain2 application? My guess was add to domain2, but I cannot be sure because I don't have the required things to test it.
Furthermore, what if domain2.com were in https, means I am calling from http to https, will this works?
and how about IE?
You should add it on http://domain2.com because Access-Control-Allow-Origin is permission for http://domain1.com to get information from http://domain2.com.
Note that (*) symbol means that domain allows access to everyone, so you need to be careful with that. Better option would be:
Access-Control-Allow-Origin: http://domain1.com
It work fine for IE and for https:
Access-Control-Allow-Origin: http://domain1.com, https://domain1.com
Take a look for more information here.