1

I'm trying to load external content into an iframe, & it is working in Chrome & Firefox, but it won't load in Safari. In Safari I get the error message:

Refused to display 'my_content' in a frame because it set 'X-Frame-Options' to 'sameorigin'

I think the issue may be that my WordPress install is in a subdirectory:

The header for my external content includes the following:

 X-Frame-Options: sameorigin
 Content-Security-Policy: frame-ancestors 'self' https://example.com
 X-Content-Security-Policy: frame-ancestors 'self' https://example.com

This article lists a number of possible reasons for the issue with Safari & SAMEORIGIN https://halfelf.org/2018/safari-and-sameorigin/. I don't have any extra X-Frame-Options in my .htaccess file, so I'm wondering if the issue is related to my WordPress install being located in a subdirectory. Is there a workaround for this? Or is this caused by something else?

  • And the "external content" is on the same or different hostname? – MrWhite Dec 20 '18 at 17:26
  • @MrWhite It's on a different hostname – megseoh Dec 20 '18 at 17:29
0
X-Frame-Options: sameorigin

By itself (and in older browsers) this would certainly deny access. However, in compliant browsers you would expect the Content-Security-Policy: header to override this.

Assuming you have control over this external content, have you tried setting this header to:

 X-Frame-Options: allow-from https://example.com

Or

 X-Frame-Options: sameorigin, allow-from https://example.com

(Although Safari may not support the allow-from directive.)

Or, removing this header altogether?

I'm wondering if the issue is related to my WordPress install being located in a subdirectory.

I don't see how having WordPress installed in a subdirectory would have anything to do with this?

0

Someone with much more knowledge about this fixed it for me. I'm posting the answer here in case it can help someone else:

We have made some changes and implemented a way to allow [external content] to be displayed using the Content-Security-Policy directives, instead X-Frame-Options. X-Frame-Options used to be deprecated, and was un-deprecated recently with any CSP directives superceding all X-Frame-Option directives, as per RFC 7034.

Please note however, there were many issues with Safari iFrames support, as it does not fully comply with specifications (contrary to what it claims).

After a thorough investigation, Safari supports CSF from version 10+ (latest is 12).

  • However, support is only available if X-Frame-Options is undefined.
  • If X-Frame-Options is defined, then that super-cedes CSF, contrary to MDN specs.
  • Safari and WebKit-based browsers do not support X-Frame-Option’s allow-from directive, preventing specific sites from being granted access.
  • And as such, does not support multiple domains for whitelisting.

We are now using Content-Security-Policy directives to dictate iFrame whitelisting, without X-Frame-Option directives.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.