Perhaps it comes to your attention after a security penetration test or perhaps because you are trying to prevent some party hijacking your site or overlaying it with advertisements. Either way the X-Frame-Options header is a good one to always include in website responses to improve your site’s security and provide some safety to it’s visitors.
This header specifies to a browser how your site can be displayed within a Frame (or iFrame). A Frame allows one web page to display content from another site within it (often in a way that isn’t obvious to the viewer). You might not think this is an issue, it’s a public web page after all, but it’s never that simple. What if someone has registered a common misspelling of your domain name and was displaying your site on it, using an iFrame? They could be overlaying advertisements or presenting a fake login page and it would all look entirely authentic, because, well, it would be your site’s content – just served from somewhere else. There’s no quicker way to lose customer trust than when a malicious actor abuses this feature to their advantage. There are genuine uses for Frames, but very likely, none you rely upon.
Setting the X-Frame-Options header on all your responses is a simple way to prevent issues of this kind. There are three possible values; DENY, SAMEORIGIN and ALLOWFROM;
•DENY will prevent the display of your site’s content in a Frame, even by another page on your site. This is often OK but has a habit of breaking Java based applications.
•SAMEORIGIN is the most commonly used setting and means pages on your website can be included in Frames, but only on other pages within the same website.
•ALLOWFROM is rather fine grained and rarely used – if it’s something you need, you probably know what it is you need to do – if not, give us a call.
As we’re always saying, a powerful benefit of using a load balancer is that we only have to make changes in a single place in order to deploy this header to all our servers. We don’t need to rely on developers or Apache reconfigurations. Just import a jetPACK configuration template and assign a flightPATH traffic rule to whichever Virtual Service(s) you wish to protect.
flightPATH is a dynamic, event-based rule engine developed by edgeNEXUS to intelligently manipulate and route load balanced IP, HTTP and HTTPS traffic. It is highly configurable and powerful, yet very easy to use.
The rule only adds the header if it doesn’t exist so it’ll work even where our web servers already insert it or only insert it for specific pages. This rule should be part of your standard Virtual Service configuration – you’ve nothing to lose whatever the site although of course, testing is always recommended. You can download the jetPACK on the edgeNEXUS Github site here.
This is one of many flightPATH rules we’ve developed, which you can deploy to improve the security of your site and it’s users. For more around security related HTTP Headers, check out these articles:
- Simplifying Security HTTP Headers with edgeNEXUS Traffic Management: X-Content-Type-Options
- How to Secure HTTP Traffic and Protect Users with the HTTP Strict Transport Security Header
