I am using an iframe to show a calendar on it. But I keep getting the following;
Refused to display 'https://cal.mixmax.com/user1' in a frame because
an ancestor violates the following Content Security Policy directive:
"frame-ancestors 'self' https://mail.google.com
https://inbox.google.com https://.force.com https://.mixmax.com".
I tried to have the meta for Content-Security-Policy as the following but no luck.
<meta http-equiv="Content-Security-Policy"
content="frame-ancestors 'self'
https://mail.google.com
https://inbox.google.com
https://*.force.com
https://*.mixmax.com">
Any idea how to overcome it?
The problem is not a misconfiguration on your side, it's on the CSP directive on Mixmax side. They have the following directive on their page:
content-security-policy:
frame-ancestors 'self'
https://mail.google.com
https://inbox.google.com
https://*.force.com
https://*.mixmax.com;;
frame-src:
https://*.stripe.com
https://*.facebook.com
https://*.mixmax.com;;
So you cannot frame it, unless you are from any of the listed domains.
One way to overcome that is to create a proxy on your site, access MixMax on the behalf of the client, and send the data to your frame, as CSP is client-enforced only.
Related
I'm building a NextJs application, and I'm trying to set a secure header in my project's next.config.js file. and every time i request to google like adsense and other default google services it is also blocked, is there a way to handle this, so that it is not blocked
this is my code
const ContentSecurityPolicy = `
default-src 'self';
script-src 'self' 'unsafe-eval' 'unsafe-inline' *.google.com *.doubleclick.net *.googleadservices.com *.googlesyndication.com *.googletagmanager.com *.google-analytics.com;
There are likely two root problems or your errors:
An error message says "Content Security Policy: Duplicate script-src directives detected. All but the first instance will be ignored." As the CSP you shown does not have duplicate script-src, it could be from another CSP. CSP can be defined in both response header and as a meta tag. Check both and see if one of them has multiple script-src defined. It is ok to have multiple CSPs with one script-src each. As content has to pass all policies, another CSP can only make it stricter.
You have not defined frame-src. There are errors due to iframes, and they fall back to default-src in your CSP, which only allows 'self'.
Refused to execute a script because its hash or 'unsafe-inline' does not appear in the script-src directive of the Content Security Policy.
This is happening with Google Ads. My Nginx has:
add_header Content-Security-Policy "frame-ancestors 'self'";
What do I add/change to fix that error so my google ads show?
There are likely multiple CSPs active, and all content needs to pass all policies. Check the response headers and meta tags for other CSPs and modify/remove them to have a single CSP.
This question already has an answer here:
What is happening when I have two CSP (Content Security Policies) policies - header & meta?
(1 answer)
Closed 2 years ago.
We are working on a web project where the Content Security Policies are enforced via HTTP headers and via meta tags as well. There is a default set of properties which are a part of the HTTP header and each page specifies the additional policies by means of a meta tag in the document header.
One of the page in the project loads content inside an iframe. The Content-Security-Policy in the HTTP header for that page is
Content-Security-Policy: frame-src *;
and the page has the following meta tag in it's document header
<meta http-equiv="Content-Security-Policy" content="default-src none;"/>
It is mentioned in the MDN Web Docs that the fallback order is frame-src -> child-src -> default-src. In-spite of setting frame-src in the HTTP header, I get the following error message in the browser console (Tried on Google Chrome and Microsoft Edge):
Refused to frame '<url here>' because it violates the following Content Security Policy directive: "default-src none". Note that 'frame-src' was not explicitly set, so 'default-src' is used as a fallback.
Also,
Moving both the policies either to the HTTP header or to the
meta tag works as expected
The more general page above that frame-src one on Content Security Policy explains what you are seeing:
Multiple content security policies
CSP allows multiple policies being specified for a resource, including via the Content-Security-Policy header, the Content-Security-Policy-Report-Only header and a <meta> element.
You can use the Content-Security-Policy header more than once... Adding additional policies can only further restrict the capabilities of the protected resource.
So with multiple CSPs, it’s like all of them are in play and not, as you see to want, that they are combined into one combined policy. So in your example, you effectively have frame-src set to none (since you have a default-src and no specific override for frame-src) so opening it up later does not work.
With Neo4j community version 3.1.1, I successfully embedded the Neo4j browser in an iframe in a web application I created. With version 3.2.0, the following error occurs when trying to view the browser through an iframe:
Refused to display 'http://xxxxxx:7474/browser/' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'none'".
Is there a way to configure the Neo4j server to set Content-Security-Policy: frame-ancestors 'self' or to the specific address where I am running Neo4j?
This behavior is due to the following headers (as for Neo4J 3.2.1):
Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY
Those headers are hardly enforced by the org.neo4j.server.web.StaticContentFilter that is statically loaded by org.neo4j.server.web.Jetty9WebServer.loadStaticContent(SessionManager, String)
So for now, it seems there is no option or parameter that can be used to by-pass this security.
Any update is welcome !
Does Content-Security-Policy ignore X-Frame-Options, returned by a server, or is X-Frame-Options still primary?
Assuming that I have:
a website http://a.com with X-Frame-Options: DENY
and a website http://b.com with Content-Security-Policy: frame-src a.com
will browser load this frame?
It is unclear.
On the one hand, http://a.com explicitly denies framing.
On the other hand, http://b.com explicitly allows framing for http://a.com.
The frame-src CSP directive (which is deprecated and replaced by child-src) determines what sources can be used in a frame on a page.
The X-Frame-Options response header, on the other hand, determines what other pages can use that page in an iframe.
In your case, http://a.com with X-Frame-Options: DENY indicates that no other page can use it in a frame. It does not matter what http://b.com has in its CSP -- no page can use http://a.com in a frame.
The place where X-Frame-Options intersects with CSP is via the frame-ancestors directive. From the CSP specificiation (emphasis mine):
This directive is similar to the X-Frame-Options header that several
user agents have implemented. The 'none' source expression is
roughly equivalent to that header’s DENY, 'self' to SAMEORIGIN,
and so on. The major difference is that many user agents implement
SAMEORIGIN such that it only matches against the top-level
document’s location. This directive checks each ancestor. If any
ancestor doesn’t match, the load is cancelled. [RFC7034]
The frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored.
An older question indicated this did not work in Firefox at that time but hopefully things have changed now.
UPDATE April 2018:
Content Security Policy: Directive ‘child-src’ has been deprecated. Please use directive ‘worker-src’ to control workers, or directive ‘frame-src’ to control frames respectively.
Looks like child-src is now the deprecated one and frame-src is back.
None of your hypotheses are universally true.
Chrome ignores X-Frame-Options.
Safari 9 and below ignore CSP frame-ancestors.
Safari 10-12 respect the CSP frame-ancestors directive, but prioritize X-Frame-Options if both are specified.
The answer was found by testing in practice.
I have created two web-sites and reproduced the described situation.
It seems like X-Frame-Options is primary.
If target server denies framing, then client website cannot display this page in iframe whichever values of Content-Security-Policy are set.
However, I haven't found any confirmations in documentation.
Tested on Chrome 54 and IE 11.