The web – as the metaphor suggests – is all about links between otherwise independent website hosts. A user can explicitly request a website through a web client, commonly a browser application. Websites, however, are able to embed other sites and render an arbitrary amount of implicit requests. Web browsers load websites in so-called sandbox environments. For protecting the user from data leakage across independent hosts, that is, each website runs in an isolated container. Yet, many use cases require an embedding interface for developers. With the iframe
element, web standards specify a single way to achieve embeds under strict constraints.
Reasons to Embed Third-Party Websites
-
Providing easy access to related external apps
Such as a map route on a contact page. -
Reusing existing scoped apps
Such as a central login form in overlays. -
Safely integrating external service apps
Such as a tracking service isolated from application scope. -
Unifying access to arbitrary apps
Such as a digital adoption platform unifying a heterogeneous workspace. -
Securing legacy apps
Such as a secure access enforced on top of an outdated app.

Embeds are Limited by Design
Although the iframe
element is the declared interface for embeds, many caveats and limitations apply. In particular: whether or not a web application can be embedded is decided by the respective host. Many applications deny web browsers permission to render it in embeds. To deny embeds, hosts serve website page resources with the following header:
X-Frame-Options: DENY
The
X-Frame-Options
header also allows for fine-grained control over which host is allowed to embed the respective resource (ALLOW-FROM <uri>
,SAMEORIGIN
).

Here is good news: there are basically two workarounds to make arbitrary third-party embeds work in your website.
Workaround Using a Reverse Proxy
For hosts you control, embeds can easily be enabled by defining a suitable X-Frame-Options
header. In order to make sure an embed of a third-party site is not denied, you could maintain a reverse proxy application that serves third-party resources with custom headers. At that, the reverse proxy acts as a mediator that dispatches direct, explicit requests in the background.
The apparent downside of this approach is high implementation complexity. The browser identifies the reverse proxy as an individual host. Requesting different hosts' resources through this proxy thus messes with context isolation, breaks relative links, invalidates location-specific scripting information, and more.
Workaround Using a Virtual Browser
Instead of concerning with a reverse proxy service yourself, you could leverage a virtual browser solution. Virtual browsers are an emerging technology that grant application developers programmatic access to web browser capabilities within an actual browser. For the present case, you could embed any application through the request endpoint of a virtual browser instance.
Check out our Embed Anything use case to get started with virtual browser embeds.
Embed Anything with Webfuse
There are two types of virtual browsers. Popular with browser testing or web automation, the most popular approach is to spin up an actual browser on a remote node and stream input and output back and forth. This grants access to the latest browser technologies, but is perceivably slow on the user's end. The alternative is given with actual browser applications that serve websites like hosts do, like Webfuse. Webfuse is an embeddable web browser-as-a-service. It is hsighly configurable: enforce certain security measures, black- or whitelist hosts, inject custom code... the list goes on. Webfuse is able to help with all the aforementioned reasons to embed websites you do not control. Elaborate embedding use cases, such as providing a DAP (digital adoption platform), can highly benefit from integrating with Webfuse.
How it works: Step-by-step
1. Create a Solo Space
Create a solo space – a virtual web session endpoint that replaces a direct request.
2. Define Embed URL
Configure the URL of the website you want to embed. It works with any site on the web.
3. Hide Session UI
Hide the session UI (a virtual browser tab bar) for a seamless experience when embeding a Webfuse Session on behalf of the original website.
