I have a website that has to be served under HTTPS
However, there is a section of the site that displays BBC news stories within an iframe which is in a popup window. Here the content is not shown as both browsers say the BBC content is insecure (i.e.mixed content).
I have tried setting the header Content-Security-Policy:
to
"default-src 'self' *.my_domian.net http://*.my_domian.net http://*.bbc.co.uk *.fonts.com 'unsafe-inline' 'unsafe-eval';"
Which has an effect on other content so it is working. I have also checked the headers are sent.
However, both Chrome and Firefox continue to tell me the BBC content is insecure and it isn't shown in the iframe.
Is it possible to allow content from bbc.co.uk on a secure site ?
Have I miss understood the purpose of Content-Security-Policy ?
I have also tried frame-src in the header with no luck.
Thanks
CSP level 2 is already being applied in Chrome, and level 2 has additional frame handling.
see here: https://www.w3.org/TR/CSP2/#directive-frame-ancestors
and here: https://www.w3.org/TR/CSP2/#directive-frame-src
frame-src is being deprecated, user frame-ancestors
Related
I currently just use an AWS S3 Bucket to be able to show some of my HTML canvas animations, and never had issues until I created an iFrame for an ad platform that versions using a feed called Celtra.
I tried ?embed=true and target="_blank" mentioned in another question where the policy was SAMEDOMAIN, and not surprisingly neither worked.
Do I need to use a Create Object Lambda Access Point? According to Mozilla, DENY & SAMEORIGIN are the only option.
ALLOW-FROM uri
This is an obsolete directive that no longer works in modern browsers. Don't use it. In supporting legacy browsers, a page can be displayed in a frame only on the specified origin uri. Note that in the legacy Firefox implementation this still suffered from the same problem as SAMEORIGIN did — it doesn't check the frame ancestors to see if they are in the same origin. The Content-Security-Policy HTTP header has a frame-ancestors directive which you can use instead.
Yes, you have to use Lambda#Edge func to add custom HTTP response headers to AWS S3 bucket.
But judging by this topic, this one, and this doc, AWS does not add X-Frame-Options header on its own. Therefore your HTML canvas animations should not be blocked in the iframe.
If you wish to allow iframing at miltiple locations, the X-Frame-Options is not flexible enough. Use Conrent-Security-Policy (CSP) HTTP header with the frame-ancestors directive.
Conrent-Security-Policy: frame-ancestors *;
will allow iframing at any locations, while
Conrent-Security-Policy: frame-ancestors example.com friends.com;
allows to embed page have published this header only in example.com and friends.com sites only.
UPDATE
The HTTP header with white list of domains allowed to embed iframe:
`Conrent-Security-Policy: frame-ancestors example.com friends.com allowed_site.net`
must be published by your s3.console.aws.amazon.com/s3/buckets/advancedbanners page. This page should grant the permissions to embed itself.
I am not shure you can to publish CSP header on AWS S3 without Lambda#Edge func. You have to use exactly HTTP header, since frame-ancestors is not supported in the <meta http-equiv="Conrent-Security-Policy" content=" directives_here "> meta tag.
And you have to find a way to stop publishing the X-Frame-Options(XFO) header on AWS S3 because of Safari bug - XFO does not obsolete in favor CSP.
Our application was working just fine, but recent changes in Safari caused our application to break.
Safari 13.1 starts blocking applications embedded in Shopify using an iframe.
The error it throws is:
refused to load https://xxdddddd.com/admin/auth/login because it does not appear in the frame-ancestor directive of content security policy.
We tried all sorts of content security policy and chrome and Firefox works just fine but safari always breaks,
We removed that header altogether.
We even added:
header("Content-Security-Policy: frame-ancestors * 'unsafe-inline' 'unsafe-eval' img-src * data:");
header("Sec-Fetch-Dest: iframe");
header("Sec-Fetch-Mode: navigate");
header("Sec-Fetch-Site: cross-site");
We tried all sorts of combinations, but it failed every time in Safari. I can find that several of other applications work just fine in embedded mode in Shopify and Safari 13.1, so it definitely means it is possible.
One thing I noticed is that the URL needs to be changed post authorization and in our cast it is not changing as Safari blocks, but in other applications it changes the URL in the browser. However I found nothing different in their code using view-source. I tried to replicate all headers as well. They are giving, but nothing worked,
Your CSP frame-ancestors * 'unsafe-inline' 'unsafe-eval' img-src * data: is completely wrong:
directives blocks should be comma-separated
the frame-ancestors directive does not supports 'unsafe-inline' and 'unsafe-eval' tokens,
Correct syntax CSP should look like frame-ancestors *; img-src * data:;
But the paradox is that this wrong CSP does allow frame-ancestors from any sources. After removing all unsupported sources, the effective CSP is frame-ancestors * data: in your case.
In the error:
refused to load https://xxdddddd.com/admin/auth/login because it does not appear in the frame-ancestor directive of content security policy.
confuses two things:
phrase in the frame-ancestor directive contains wrong directive name (s is omitted at the end of directive name). Is this a real Safari browser error?
the /admin/auth/ part - is this really public accessible URL? Or does this error appear in the administrator script, which could have other CSP rules?
You say in Chrome and Firefox all worked fine, but frame-ancestors * 'unsafe-inline' 'unsafe-eval' img-src * data: rules disallow images loading from any sources.
So it's possible you are editing one CSP header, but the app really have another. If you are familiar with the Safari browser console, you could check real CSP HTTP header delivered to the app's page.
Anyway, here you could test does Safari 13.1 support * in frame-ancestors (I can't do that due to Safari browser absence). It will exclude a case of a current version browser bug.
The website https://www.example.com with header content-security-policy: frame-ancestors 'self'; is unable to open with <iframe>
This website contain a shareable url like https://www.example.com/#/shareablelink which should be allowed to open in <iframe> but as header content-security-policy: frame-ancestors 'self'; also applied to this page, it is not working as expected.
Is there any way do so?
Its frontend is build on angular 5+
HTTP headers publish on the backend (server), so only the site owner can change those.
Link (https://www.example.com/#/shareablelink) with hash # works tricky:
part before # is served by server - be sends to server on click and will get reply from server (if you do not handle onClick by script in browser)
part after # is served locally in browser (by script or by built-in browser navigation) and never be sent to server
Therefore CSP HTTP header on the page https://www.example.com/#/shareablelink always will be the same as on https://www.example.com/. The part #/shareablelink normally is a scroll to '/shareablelink' anchor, or could be handled by javascript for any purposes (even send XMLHttpRequest to server, get response and change the page's content but not the HTTP header)
I have a web page that contains an iframe. The iframe is loaded with a URL call to the same server as the page. However, I get this, because I am apparently using a different port, 81:
Refused to frame 'http://my-same-server:81/' because it violates the following Content Security Policy directive: "frame-src 'self' https://*".
I realize this is a Content Security Policy issue for newer Chrome browser versions, and know that I need to change an Apache header, but am not sure to what I would change it to allow the iframe to properly load. The URL cannot use HTTPS, otherwise there are no special conditions. Any help would be grand. Thank you.
I have two web pages hosted on a.example.com and b.example. Each web page is including a script with a <script> tag, hosted on another domain and served with correct CORS headers.
At a certain point, user navigates from a.example.com to b.example.com.
Safari has here a strange behavior: the referrer and origin headers in preflight request are filled with a.example.com, making the server sending a bad value in Access-Control-Allow-Origin (and so the script can't be executed).
Is there a way to force Safari browser to send correct origin header in that kind of scenario ?
Does the cache policy for the script include Vary: Origin?
Respectively is there actually a second request after navigating to b.example.com?
If not, there is a chance that Safari is actually serving the script from cache - despite the Access-Control-Allow-Origin policy forbidding it to access the resource. Which is a conforming behavior, if the cache policy isn't configured correctly.
It seemed to be indeed a Safari bug.
The issue is not reproductible on Safari 10.0. It repro only on Safari 9.1.1 / 9.1.3.