The modern web ecosystem often requires a web page to be embedded within an iframe of another web page. This practice, while beneficial for numerous applications, may be inhibited by specific security measures employed by websites to protect their content from being shown within an iframe – a practice often referred to as “iframe busting.” The primary tools for implementing these security measures are HTTP response headers, predominantly the X-Frame-Options and Content-Security-Policy: frame-ancestors headers. This article aims to provide an in-depth understanding of these headers, their functionalities, and methods to bypass them using Requestly when required.
Dissecting X-Frame-Options and Frame-Ancestors Headers
X-Frame-Options:
The X-Frame-Options is an HTTP response header employed by servers to dictate if their content is allowed to be displayed within an iframe on an external website. It provides a level of protection against clickjacking attacks. Clickjacking is a malicious technique where an attacker tricks a user into clicking on a hidden element, leading to unintended actions. By dictating how a document can be embedded into other documents using an iframe, the X-Frame-Options header offers three directives:
– DENY: This forbids the page from being presented in an iframe, irrespective of the origin of the request.
– SAMEORIGIN: This permits the page to be displayed in an iframe only if the request is initiated from the same website.
– ALLOW-FROM uri: This directive permits the page to be displayed in an iframe only if the request originates from the specific website mentioned.
Content-Security-Policy: frame-ancestors
The frame-ancestors directive is a part of the Content-Security-Policy (CSP), a powerful response header that provides a high level of control over the resources a page is allowed to load. This directive specifies which sources are permitted to embed the page. Unlike the X-Frame-Options header, frame-ancestors can allow a page to be embedded by multiple domains, giving it more flexibility.
Remove X-Frame-Options
Some websites specify X-Frame-Options in the response header to control where the content can embed inside an iframe.
You can load the iframe on a website by removing the X-frame options from the response header.
Add the ‘frame-ancestors’ directive in CSP Header
You can achieve similar results by setting the Content-Security-Policy to use the frame-ancestors directive.
Using the directive Content-Security-Policy: frame-ancestors <source1> <source2> in the CSP headers, you can set multiple sites as parents for the iframe.
Here, the source can be one of the following:
- URL: Specify parent’s source
- ‘self’: Refers to the source from where the content is generated
- ‘none’: Indicates an empty set. It is similar to specifying X-Frame-Options as DENY.
However, if you need to open sites in iframes for internal tooling, experimentation purposes, or development & testing scenarios, you will need a tool like Requestly to do the job.
Remove response headers using Requestly
Requestly is a browser extension that lets you Modify Headers, Redirect URLs, Switch hosts, Mock API responses, Delay network requests, Insert custom scripts, and do much more. Using the modify headers rule, we can easily add, modify and remove any response Headers before it reaches the browser.
Install the Requestly and follow the instructions below to bypass the content security policy.
- The first step is to install the Requestly browser extension or desktop app.
- Once installed, open the app and create a new “Modify Response Headers” rule.
- In the rule settings, select “Remove” as the action. For the header name, enter “X-Frame-Options” or “Content-Security-Policy”.
- Click on Save to activate the rule. Now, the website you’ve specified should be able to load in an iframe.
You can also share this rule with your colleagues by inviting them to your workspace. To fast track your development process, we have also created a template to easily bypass CSP.
It’s important to note that the frame-ancestors directive of the CSP takes precedence over the X-Frame-Options header if both are present. This is because the CSP offers a more fine-grained and versatile approach to controlling embedding. By properly configuring these headers, a website can provide a strong line of defense against attacks that leverage iframes, like Clickjacking.
