Impact of X-Frame-Options response header on admin

I just spent the last few days wrestling with a problem that started showing up a month or so ago on our business web site. In WordPress admin, View details on installed plugins had stopped working. The popup happened but there was no content. Without getting into details, I discovered that the problem was that the server had been changed to set the X-Frame-Options response header to DENY, which prevents frames (<iframe> elements) from working. Since View Details uses a frame to display content from other sites, it stopped working.

I fixed it by coding the following in our .htaccess:

Header always set X-Frame-Options SAMEORIGIN

That works perfectly; content appears in plugin details frame fine now. As I said before, this used to work, so that means that at some point in the recent past, somebody at our ISP set it to DENY in the server config (probably httpd.cnf), which I could not have done because I don’t have access to the root. So it had to be their side.

My guess is that the change was made during our last wave of tweaks that needed to be made to get our site to pass a PCI scan, but I’m only guessing. I have read about a risk called clickjacking, which is a vulnerability if X-Frame-Options isn’t restricted. I know DENY would handle the clickjacking threat but I’m not sure of SAMEORIGIN. Depending on what the PCI scan looks for, I suspect that my change might break PCI compliance and will be a problem when the next scan happens. Between now and then, I want to localize the impact of the change to WordPress admin since that’s where I need it, not with my actual live site, since I don’t use frames in any of our content.

Anyway, WordPress should be changed to stop using frames for View Details and to find a method of displaying the view that doesn’t break PCI compliance for sites that need it.

For anyone out there who has experienced this problem, you now know what to do about it.