I have a Lotus Notes web application which is been loaded in to another web application, after we upgraded to domino from 9.0.1 to Domino V10.0.4 the application fails to load in this portal, the application can be accessed individually in browser but while loading in another application it fails with error
Load denied by X-Frame-Options: http://achme.com/achme.NSF/frameset?readform does not permit cross-origin framing.
any hint on fixing the error
enter image description here
It seems that your Domino- server has a header value for X-Frame-Options set.
This can either be done with a Website- Rule of type "HTTP response headers" that defines the header in the domino directory:
X-Frame-Options: SAMEORIGIN
Possible values:
X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from https://example.com/
Or it is set via notes.ini Entry:
HTTPAdditionalRespHeader=X-Frame-Options: SAMEORIGIN
Check your domino directory and the notes.ini for the setting and set it to something more relaxed if you need the page to be loaded in an iframe.
Do you happen to have changed the FQDN of your Domino server when upgrading? That might be a reason why the same setting worked in Domino 9 (old hostname) and does not work for the new server (new hostname).
Related
I am sorting out a website that will be getting pen-tested soon, we've have been asked to add the X-Frame-Options header to our server configuration. When adding the following header it gives me an error message in the console.log where we are using iframes
-- nginx header --
add_header 'X-Frame-Options' "SAMEORIGIN";
-- Error --
`Refused to display 'https://api.domain.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
Obviously I understand the security reasons for this header but our website has an iframe that we simply cannot change & it is on a different domain e.g oldapp.domain.com rather than api.domain.com.
I would have used the ALLOW-FROM uri directive to allow from this other domain, but this directive is no longer recommended, is there an alternative to ALLOW-FROM uri that will enable me to simply add a domain that can be allowed to display iframe content?
For all browsers except some older ones (like IE) you should use Content-Security-Policy with the frame-ancestors directive instead. With CSP frame-ancestors you can use wildcards *.domain.com or multiple sources "oldapp.domain.com api.domain.com www.domain.com".
X-Frame-Options ALLOW-FROM only accepts one uri, you will likely have to dynamically set the uri from a list of allowed hostnames based on the incoming request. Alternatively you can set the value to SAMEORIGIN if you don't need to fully support IE and other outdated browsers as X-Frame-Options will be disregarded if CSP frame-ancestors is present.
After an windows update on our windows web server IIS 8 it, iframe of the hosted sharepoint 2013 stopped working from an external domain.
The server seems to force X-FRAME-OPTIONS SAMEORIGIN. This value is not set in web.config or in IIS Manager under HTTP Response Header.
I've tried to add a HTTP Response header in both IIS Manager and in web.config but it doesnt help.
If i dont add anything i get this error:
Refused to display 'http://SP-SITE' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
When i add the X-FRAME-OPTIONS ALLOW-FROM http://Other-url i get this error:
Refused to display 'http://SP-SITE' in a frame because it set multiple 'X-Frame-Options' headers with conflicting values ('SAMEORIGIN, ALLOW-FROM http://Other-URL, ALLOW-FROM http://Other-URL'). Falling back to 'deny'.
Does anyone know how i should find where the SAMEORIGIN value is set or how to override it or change it?
Hi I have a windows server with IIS 10 on where I am hosting angularjs web apps with the help of IIS-Node. I've been trying to harden the response headers and I find that Im doubling up on some of them.
For instance: x-frame-options: is listed twice the first time it is loaded it is SAME ORIGIN which is not set in either applicationHost.config or webhost.config but is being added from somewhere Im not aware of, the second x-frame-options: is shown as DENY which is what I expect it to be as I did set this using applicationHost.config.
A similar thing is happening with cache-control in the browser (chrome) it is shown as public, max-age=0,No-store when I only set it as No-store using applicationHost.config. So again cache-control:public, max-age=0, is being set somewhere else, not by me.
Please can any one tell me how to turn off these unwanted response headers?
I have searched IIS and Googled but I keep getting pointed back toward applicationHost.config or web.config. Thanks in advance.
X-Frame-Options HTTP header field is used for prevention against clickjacking attacks. Is it possible to insert X-Frame-Options into every HTTP response?
for Apache web server use mod_headers :
Apache mod_headers
and add "Header always append X-Frame-Options SAMEORIGIN".
There are three settings for X-Frame-Options:
SAMEORIGIN: This setting will allow page to be displayed in frame on the same origin as the page itself.
DENY: This setting will prevent a page displaying in a frame or iframe.
ALLOW-FROM uri: This setting will allow page to be displayed only on the specified origin.
In some web applications I have noticed there are to options set for X-Frame options header like
X-Frame-Options: DENY DENY
(DENY option should have been wrongly added twice).
In this case, will the browser obey to such header as it is obeying for
X-Frame-Options: DENY.
or else will it eliminate this header option as meaningless by considering "DENY DENY" as meaningless
if it is obeying, what will happen for scenarios like
X-Frame-Options: DENY SAMEORIGIN
Browsers handle X-Frame-Options: DENY DENY as if it were just X-Frame-Options: DENY.
Safari previously had a bug that caused it to ignore X-Frame-Options if it had a duplicate value, and Chrome inherited the same bug. And Firefox also previously had pretty much the same bug.
But they’ve since all been fixed: They behave the same as they would if the value was given once.
if it is obeying, what will happen for scenarios like
X-Frame-Options: DENY SAMEORIGIN
For that case, what Mozilla ended up implementing (and Safari and Chrome ended up following) is:
use the most restrictive policy… if the framing situation violates any of them, blocks the load
Thus the browser behavior for X-Frame-Options: DENY SAMEORIGIN is DENY (most restrictive).
So, unfortunately while there is no authoritative spec to point to on what the required behavior is if there are multiple values for the header—because the X-Frame-Options spec, RFC 7034 doesn’t actually state what the requirements are—in practice, the current Safari/Chrome/Firefox behavior is the expected behavior. Not sure what IE/Edge does, but if it’s different from Safari/Chrome/Firefox on this, then that’d be a bug that would need to be fixed in IE/Edge too.