Zendesk does not allow iframing of Zendesk due to the inherent security risks involved in iframing a web application.
The security risk, UI Redressing, or, as it's more commonly known, "clickjacking", is a class of attack that uses an iframe element on a web page that is actually overlaying another website.
As in the example described in this blog post, users can be lured into thinking that they are accessing a separate website when in fact they are allowing the hacker into a website they've already logged into (their online banking account, for example).
Zendesk prevents the iframing of Zendesk by setting an HTTP header (X-Frame-options) to SAMEORIGIN for all server responses. This policy took effect on June 30th, 2013.
45 Comments
Hey Tal!
Interesting. I see that my colleague Tod has taken over your ticket; you're definitely in good hands. He's been conferring with some folks internally, so we'll continue to help you out there!
No change to this policy per my most recent ticket. It would be good that our users don't have to leave our app to get help. It makes for a more confusing user experience.
Not happy about this. We don't want to have to replicate all the information we already have on Zendesk on another website just so we can access it in-app.
We have a specific use case where we would really like some form Andrew Sharpe's idea implemented (configurable origin settings to allow a single domain to embed the Zendesk app in an iframe).
I understand the technical challenges on your side of the fence, but this would be a huge benefit to our company and customers.
Our particular use case is the following: I actually DO want to perform a cross-site scripting scenario where my application sends javascript and manipulates form data on the ticket creation page. I have already setup the proper javascript communication where the origin is checked at both ends (so security should not be an issue in that regard). The problem that I can't overcome is the Zendesk server ALWAYS responding with an X-Frame-Options: SAMEORIGIN header.
All we need is the ability to configure the following header:
This doesn't pose any more of a security risk than what is already inherent in our application. As a developer, I don't buy the "for security reasons" line. I DO understand that it may require development effort on your side to allow configurable header options per server instance. However, I know that that effort is far less for you than if would be for your many customers who want to have this functionality and are forced into the API/custom UI approach you seem to want everyone to use.
Please just let us configure the response headers per server (or at least this one header option). It's really not a huge undertaking for you guys and it will save a lot of your customers a good bit of development time and headache. No one wants to write a UI to display what Zendesk so wonderfully provides.
Thank you for reading this.
Technical info on the X-Frame-Options header.
+1
There is a workaround.
On your server, you have to create a proxy endpoint, (ex: https://myzendeskproxy.myproduct.com
It will forward all the traffic to Zendesk, but you can cut out X-Frame-Options header from all responses.
Moreover, you will have to analyze the body of the response (from Zendesk), and replace all the references of the Zendesk domain, with your proxy address.
Then you can easily integrate Zendesk, to any iframe you want
And thanks Zendesk team, for such a great and convenient product! You are doing a great job! well done!
+1
+1
I've submitted product feedback on this:
https://support.zendesk.com/hc/en-us/community/posts/360036640934-X-Frame-Options-Embedding-Zendesk-Help-Center
Thanks for taking the time to share this with us Cakra!
It would be very important to have this feature added. We need to have flexibility to embed iframes with our support portals when and how we want.
I purchased the subscription but now I'm considering moving to somebody else if you cannot provide this.
If your widgets were at least useable that could sort things out, but they are so ugly and simple that I don't see any alternative solution within your product.
Hi Jessie Schutz, Brett Bowser
I wanted to address the fact that I can't embed pages from zendesk.com into zdcontect.com (custom support app iframe).
My usecase is to have a support app in the top nav-bar that will show the moderation queue so agent wouldn't need to switch between apps (icon should show the number of items in the moderation queue).
The response I got from your support over a year ago was that even though this option is available internally within Zendesk, it is not exposed to customers for some reason.
I ask you to please reconsider it again.
Thanks!
Please consider option to allow a single domain for Iframing
A lot of customer really need it to easily integrate HC in their website
It's very important for us
Thanks
Hello Cust Admin KN,
Appreciate you sharing with us, I would recommend however posting in our product feedback forum so our development team can consider this change in a future update.
Best regards.
sorry but i am not authorized....
This is an issue for us too. Quite ironically, you provide a widget to embed other web content in iframe inside zendesk but you don't reciprocate.
I fully agree that allowing uncontrolled embedding of zendesk inside iFrames can be considered dangerous, but nobody is asking for that. What people want is embedding the Zendesk Help Center inside controlled area. In this areas, embedding the Zendesk Help Center does not expose our users to any more risks than using the tools we provide them.
The option of recoding completely the helpcenter using the API is ludicrous. If we have to rewrite the zendesk UI, why not rewrite it all and get rid of zendesk altogether... The reason why we pay for your services is because we don't want to do that.
Also the link you provide for the product feedback forum does not work. So you will have to tell your dev team yourself!
Please sign in to leave a comment.