Let’s say you want to make a simple dashboard page, where you’d like to use iframes to embed content from 3rd-party websites.
If those websites are serious about security, they should have protection against clickjacking attacks using a X-Frame-Options response header. As a result, you won’t be able to embed the webpage in an iframe.
For example, here is what you’ll get if you try to embed Vimeo directly on your website (yes, it is just a blank window).
This is where Surfly’s proxy can come in handy. By opening the website via Surfly, you can change the X-Frame-Options header so that it allows iframe embedding.
Below you can see an embedded page from Vimeo. This would not be possible without proxying. Note that we are not just embedding the video from Vimeo, but the whole webpage with the video, comments, and other content.
Because Surfly is using a sandboxing proxy, all the links on the page are changed on the fly, so you can navigate them, and the page will still work correctly inside the iframe.
How is this possible and am I still safe when using Surfly?
This allows the Surfly proxy to manipulate HTTP requests and responses. In this particular case, we are simply stripping out the X-Frame-Options header from the original HTTP response.
Note that by adding proxy in front of the app, we have technically created a new browsing context. It means that the changes affect data in an isolated scope, which is not the scope of the original website. Simply put, your data on the real Vimeo is still safe and protected from clickjacking attacks.
Is it all Surfly can do?
No, of course not. The possibilities of Surfly proxy are much broader than just embedding non-embeddable iframes. In future Surfly LABS experiments we will show how you can actually change the behavior of existing web applications on the fly, or even enrich them with some new functionality.