Is there a way to define a content-security-policy header specifying it should trust inline scripts/styles created from a source domain that is already whitelisted?
For instance I have the following header:
Content-Security-Policy: script-src https://www.somesite.com
From this site I load https://www.somesite.com/somescript.js which in turn dynamically creates inline styles and scripts without needing a hash or nonce.
Is this possible?
Related
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.
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.
Our website is designed based on WordPress tool and published on Azure web service. Our goal is to use google analytic for checking traffic. Due to this fact, the google analysis tag was added in the header part of our page which causes the following error:
Refused to load the script 'https://www.googletagmanager.com/gtag/js?id=??' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-eval' 'unsafe-inline' *.msecnd.net *.google.com *.gstatic.com". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
I understand that violation of the Content Security Policy is the main problem. Therefore, I added meta in the header (Content-Security-Policy:
script-src 'unsafe-inline') but the issue did not disappear. I will appreciate any help.
Since you have got a Content Security Policy (CSP) violation, you already have a first CSP published at the page.
Adding a second CSP via meta tag (or even via second HTTP header) will not solve a problem, because all sources should pass through both CSPs to be allowed.
Therefore you have to add blocked source (https://www.googletagmanager.com) in first CSP into script-src 'self' 'unsafe-eval' 'unsafe-inline' *.msecnd.net *.google.com *.gstatic.com;.
Check if your WP has some installed plugins to manage CSP, or CSP is published in the .htaccess file.
Since you have 'unsafe-eval' 'unsafe-inline' in the script-src, you should not have problems with Google Tag Manager (GTM).
Anyway you can check CSP for your GTM-XXXXXX ID - which additional scripts are loaded by GTM and which tokens are required in you specific case.
I have a web app which I want to display in an iframe in web apps with different domains. Since I have added a content-security-policy header my app refuses to display in iframe. I saw that i need to add frame-ancestors options but all the examples I see are using specific domains. How can I allow it for all domains? Is "frame ancestors *;" enough? Thanks!
Briefly - yes, * allows any sources for iframe except data:.
Pls note that frame-ancestors is not supported in the meta tag <meta http-equiv='Content-Security-Policy' content="..."> (but looks like you use HTTP header to delivery CSP, so this warn not for you).
But if you really wish to allow all frame ancestors - more reliable not specify frame-ancestors directive at all, because for now Mozilla Firefox has some bugs with it.
PS: You did not attach print screen of errors in browser console - may be iframes was block by other reason than CSP?
updated after exposed CSPs details
<html>
parent page issues CSP: default-src 'self';
since frame-src omitted, it fallback to default-src and result be: frame-src 'self'
<iframe src=''></iframe>
</html>
iframe is allowed with the same scheme://host:port as parent page loads.
'self' is tricky in that if parent loaded via HTTP:, iframe via HTTPS: will blocked in CSP2-browsers. CSP3-browsers do upgrade (see para 3) HTTP: to HTTPS:, so all OK.
If parent page issue frame-ancestors * policy, it means you allow to embed it into iframe to any another webpage.
X-Frame-Options HTTP header provide the same functionality, but it's overridden if frame-ancestor is issueed.
frame-ancestor directive does not affects <iframe> embed into page who published this CSP. It affects where it allowed to embed this page.
But <iframe> could publish its own CSP with rule frame-ancestors domain1.com domain2.com to restrict it embedding to other web-pages.
That's how it works. You could play with test of frame-ancestors to clarify details for different <iframe src=/srcdoc=.
Therefore if you embeds iframe from your own domain/subdomains, it's more safe to use:
frame-ancestors 'self';
or if you use subdomains:
frame-ancestors http://example.com https://example.com http://*.example.com https://*.example.com;
I'm serving up locally-generated untrusted content in an iframe from a service worker.
I'm trying to lock down the iframe entirely so that it can only load resources from its srcdoc, which is intercepted by a serviceworker. This means no img etc. from any other domain, but allowing javascript.
To achieve this I'm adding CSP: sandbox allow-scripts; default-src 'self' data:; script-src 'self' 'unsafe-inline'; on all assets served by the service worker, which includes the iframe root.
Loading the iframe root document works fine. But loading an image in the iframe with a relative url, so from the same origin, is not hitting the service worker - but falling through to the parent domain and thus getting a 404. If I remove the sandbox property from the CSP then the image loads, but I lose the security.
Is there a way to get this to work?
I have a demo here: https://ianopolous.github.io/sandbox
I apply the CSP headers in the service worker here:
https://github.com/ianopolous/sandbox/blob/gh-pages/sw.js#L119