How should I resolve this conflict between facebook iframes and browser security?

I have a facebook application that I built as an FBML app. Recently I noticed that FBML is deprecated and that Facebook now recommends only iframe apps. Something I initially avoided because my understanding is that iframes are not valid xhtml code, and at the time I was trying to write 100% validated code for everything.

However I also don't like building unsupported applications, so I set about changing my app to use fully rendered html pages using the iframe method of display.

My pages render perfectly on their own when I display them in their own window however they are completely blank in Safari when rendered inside a frame provided by Facebook. At first I was stumped and couldn't figure out why nothing rendered, until a friend using Internet Explorer told me he was seeing the following error:

To help protect the security of information you enter into this website, the publisher of this content does not allow it to be displayed in a frame.

So I started googling this error, and found mountains of forum discussions between confused people trying to get their frame code working and figured out it was an error that appeared overnight back in 2009 when IE8 was introduced. A开发者_如何学JAVA little more digging on the Microsoft site reavealed that it is a security feature invented by Microsoft to prevent click-jacking.

The apparent cause of this is the server sending an X-Frame-Options heading, and the response of Firefox and Internet Explorer is to display an error message about security and frames, while the response of Webkit browsers such as Chrome and Safari is to render an unhelpful blank frame. I own the hardware running the apache server and I wrote all the html, and I certainly never explicitly sent the X-Frame-Options header, so I must assume that my installation of php sends this header by default on all pages that it serves up as a blanket security enhancement (either that or Apache is doing it).

Obviously, now that I know what causes it, I could figure out who is sending the header and stop it, but my question is on of best practises: Click-jacking prevention is obviously a worthy cause, and since some part of my server chain deems it important enough to send this header without asking, clearly someone thinks it is a good idea. However, Facebook apps, by design, load content from another website within an iframe, so I'm surprised there is little or no talk that I can find about this on the internet. Is there another way around this, or is it simply a case of something that should not be turned on for a page that is intended to be viewed from within an iframe?

Furthermore, if getting rid of the header is the correct approach, does anyone know why it is getting sent and where to turn it off? I'm running on a Snow Leopard Server with the default installation of apache and php.

---

Search the Apache config files for the option

$sudo grep -ir 'x-frame-options' /etc/apache2

Credit