On the X-Frame-Options Security Header

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.

Another technique for possible attackers comes with window.name. This attribute of your browsing window (a tab, a popup and a frame are all windows in JavaScript's sense) can be set by others and you cannot prevent it. The implications of this are manifold, but just for the sake of Cross-Site-Scripting (XSS) attacks it may make things for an attacker much easier. Sometimes, when an attacker is able to inject and execute scripts on your web page, he might be hindered by a length restriction. Say, for example, your website does not allow names that exceed 80 characters. Or messages that must not exceed 140. The window.name property can help bypassing these restriction in a very easy way. The attacker can just frame your website and give it a name of his liking, by supplying it in the frame's name attribute. The JavaScript he will then execute can be as short as <svg/onload=eval(name)>, which means that it will execute the JavaScript specified in the name attribute of the frame element.

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.

All posts

  1. Reference Sheet for Principals in Mozilla Code (Mon 03 August 2020)
  2. Hardening Firefox against Injection Attacks – The Technical Details (Tue 07 July 2020)
  3. Understanding Web Security Checks in Firefox (Part 1) (Wed 10 June 2020)
  4. Help Test Firefox's built-in HTML Sanitizer to protect against UXSS bugs (Fri 06 December 2019)
  5. Remote Code Execution in Firefox beyond memory corruptions (Sun 29 September 2019)
  6. XSS in The Digital #ClimateStrike Widget (Mon 23 September 2019)
  7. Chrome switching the XSSAuditor to filter mode re-enables old attack (Fri 10 May 2019)
  8. Challenge Write-up: Subresource Integrity in Service Workers (Sat 25 March 2017)
  9. Finding the SqueezeBox Radio Default SSH Passwort (Fri 02 September 2016)
  10. New CSP directive to make Subresource Integrity mandatory (`require-sri-for`) (Thu 02 June 2016)
  11. Firefox OS apps and beyond (Tue 12 April 2016)
  12. Teacher's Pinboard Write-up (Wed 02 December 2015)
  13. A CDN that can not XSS you: Using Subresource Integrity (Sun 19 July 2015)
  14. The Twitter Gazebo (Sat 18 July 2015)
  15. German Firefox 1.0 ad (OCR) (Sun 09 November 2014)
  16. My thoughts on Tor appliances (Tue 14 October 2014)
  17. Subresource Integrity (Sun 05 October 2014)
  18. Revoke App Permissions on Firefox OS (Sun 24 August 2014)
  19. (Self) XSS at Mozilla's internal Phonebook (Fri 23 May 2014)
  20. Tales of Python's Encoding (Mon 17 March 2014)
  21. On the X-Frame-Options Security Header (Thu 12 December 2013)
  22. html2dom (Tue 24 September 2013)
  23. Security Review: HTML sanitizer in Thunderbird (Mon 22 July 2013)
  24. Week 29 2013 (Sun 21 July 2013)
  25. The First Post (Tue 16 July 2013)