This blog post about X-Frame-Options was originally published on the Mozilla Security Blog
A few weeks ago, Mario Heiderich and I published a white paper about the X-Frame-Options security header. In this blog post, I want to summarize the key arguments for settings this security header in your web application.
X-Frame-Options is an optional HTTP response header that was introduced in 2008 and found its first implementation in Internet Explorer 8. Setting this header in your web application defines if it works within a frame element (e.g.,
iframe). The syntax for this header provides three options, ALLOW-FROM, DENY or SAMEORIGIN. Not sending this header implies allowing frames in general. ALLOW-FROM, however, allows whitelisting a specific origin. The opposite is, of course, DENY which means that no website is ever allowed to display your website in a frame. A common middle ground is to send SAMEORIGIN. This means that only websites of the same origin may frame it.
This blog post will highlight some attacks than can be thwarted by forbidding the framing of your document. First of all, Clickjacking. This term has gained major attention in 2008 and includes a multitude of techniques in which an evil web page can secretly include yours in a frame. But the author of this evil website will make your website transparent and present buttons on top of it. Anyone visiting this evil page will then click on something seemingly unrelated, which will actually result in mouse clicks in your web application.
A wide class of attacks on other websites leverage missing security features in the browser. Most modern browsers provide hardened security mechanisms that may easily thwart problems with content injections. The problem lies, as so often, in backwards compatibility. The most recent browser versions are obviously more secure than the previous ones. But when somebody frames your website, they can tell it to run in a compatibility mode. This feature only applies to Internet Explorer, but it will bring back the vintage rendering algorithms from IE7 (2006). In Internet Explorer, the document mode is inherited from the top window to all frames. If the evil websites runs in IE7 compatibility mode, then so does yours! This is an example of how IE7 compatibility can be triggered in any website:
<meta http-equiv="X-UA-Compatible" content="IE=7" />
If your website would not allow to be framed, your IE users were not at risk.
These and many other attacks are possible if you allow your web page to be displayed in a frame. Just recently, Isaac Dawson from Veracode has published a report about security headers on the top 1 million websites, which shows, that only 30,000 of them currently supply this header. However, the fact that many other sites are vulnerable to these sort of attacks is not a good reason to leave your website unprotected. You can easily address many security problems by just adding this simple header to your web application right away: If you're using Django, check out the XFrameOptionsMiddleware. For NodeJS applications, you can use the helmet library to add security headers. If you want to set this header directly from within Apache or nginx, just take a look at the X-Frame-Options article on MDN.