All posts

What is Browser Isolation? Secure Browsing with Remote Browser Isolation (RBI)

What is Browser Isolation? Secure Browsing with Remote Browser Isolation (RBI) (KAEMI)

The web browser is the most important work tool today, and at the same time one of the biggest entry points for attacks. Whether research, SaaS applications, webmail, or cloud portals: a large share of daily work happens in the browser, and that is exactly where the endpoint loads and processes third-party code from often unknown sources. Traditional protective measures such as blocking entire website categories fall short here.

Browser isolation starts at exactly this point: it separates the actual browsing from the endpoint and moves it into a sealed-off environment. This article explains what browser isolation is, how Remote Browser Isolation (RBI) works technically, which methods exist, what it protects against, and where its limits lie.

What is browser isolation?

Browser isolation (also called "remote browsing") is a security approach that separates internet browsing activity from the local loading and display of web pages. Normally, the browser loads a page's content and code directly on the endpoint and executes it there. Since this code frequently comes from unknown sources, browsing is risky from a security perspective. Browser isolation moves the execution of web content into an isolated environment, shielding users and the network from potentially malicious code.

The basic idea fits the Zero Trust principle: no website code should be trusted by the endpoint by default. Even a page a user has already visited 99 times without incident can be compromised on the 100th visit. Browser isolation applies this "never trust, always verify" rigorously to browsing.

Why is the browser a risk?

Websites and web apps consist of HTML, CSS, and JavaScript. While HTML and CSS only provide formatting, JavaScript is a full-fledged programming language: powerful, but also open to abuse. Numerous attacks are therefore possible through the browser:

  • Drive-by downloads: merely loading a page triggers the download of a malicious payload (usually via an unpatched browser vulnerability), without any action by the user.
  • Malvertising: malicious code is injected into legitimate ad networks and executed when the ad is served.
  • Clickjacking: the page is built so that the user clicks unintentionally, for example to steer them to unsafe pages or trigger downloads.
  • Redirect attacks: a legitimate URL silently redirects to a page controlled by the attacker.
  • On-path attacks: attackers use browser vulnerabilities to manipulate displayed content or impersonate the user.
  • Cross-site scripting (XSS): injected code steals session cookies or login tokens, for example, and thereby takes over user sessions.
  • Zero-day exploits: attacks on still unknown, unpatched vulnerabilities; hard to prevent, but their impact can be contained through isolation.

Firewalls, VPNs, and network access control secure the internal network. Browser isolation stops attacks that originate in the browser itself.

How Remote Browser Isolation (RBI) works

Remote Browser Isolation (also called "cloud-hosted browser isolation") loads web pages and executes their code on a cloud server, far away from the endpoint and the corporate network. The process, step by step:

  • Start the session: the user opens their browser as usual and calls up a page.
  • Processing on the remote server: the request is forwarded to an isolated browser environment in the data center or cloud instead of being processed locally.
  • Isolated sandbox: the page is loaded in a sealed-off sandbox; scripts and plugins run safely there, without access to local files or the endpoint.
  • Only the display is streamed: instead of the complete page data, the device receives nothing but the visual output. Malicious elements never reach it.
  • Secure interaction: clicks, keystrokes, and form input are transmitted to the server, processed there, and the result is played back as display output.

When the session ends, the remote environment is discarded along with all cookies and downloads. Any compromise remains confined to the isolated session.

Comparing the rendering methods

How the remote server delivers content to the endpoint differs technically, with consequences for security, compatibility, and latency. Three methods are common:

Pixel pushing (streaming)

The page is rendered entirely on the server; the endpoint receives only an interactive image or video stream. Malicious content reliably stays on the server. In return, the method needs a lot of bandwidth and can create noticeable latency.

DOM reconstruction

The page is loaded in an isolated environment, cleaned of potential attacks, and then sent to the local browser in rebuilt form, where the code is executed a second time. The experience of the original page is preserved better than with pixel pushing. However, unsafe third-party code can still end up on the device.

Network Vector Rendering (NVR)

Instead of page code or an image stream, the "draw" commands of the Skia graphics engine (used by Chrome, Chrome OS, and Firefox, among others) are intercepted, encrypted, and streamed to the local browser. Because only drawing commands are transmitted, NVR can be faster and more secure than the other two methods and remains compatible with almost any page. Cloudflare relies on NVR in its RBI service.

Other forms of browser isolation

Besides RBI, there are two other approaches:

  • On-premise isolation: works like RBI but runs on a server that the company operates itself and fully controls.
  • Client-side isolation: browsing is sealed off directly on the endpoint, using virtualization (a separate virtual machine below the operating system, controlled by a hypervisor) or sandboxing (a self-contained test environment).

The decisive difference: with client-side isolation, potentially malicious content is actually loaded onto the device. The physical separation of malicious code and endpoint, the core principle of RBI and on-premise isolation, is missing here; a residual risk remains.

What RBI protects against, and further use cases

Because browser sessions run in a controlled environment, malicious code and harmful content stay away from the endpoint and the network. A drive-by download, for example, only hits the remote server and is deleted along with the session. Beyond pure browser protection, RBI delivers additional value in combination with other Zero Trust services:

  • Protection against malware: combined with HTTPS inspection and a Secure Web Gateway (SWG), the spread of viruses, ransomware, and other malware can be contained.
  • Defense against multi-channel phishing: together with cloud-based email security, RBI defuses attacks via embedded email links. Even if a user enters data, the real credentials remain protected.
  • Control of third-party access: through integration with identity and access management (IAM), policies for high-risk external users can be automated, for example to prevent credentials from being entered on certain pages.
  • Limiting data exfiltration (DLP): since browsing takes place remotely, the outflow of sensitive data through the browser can be effectively contained.
  • Continuing to use legacy applications: RBI enables secure access to legacy web applications that are no longer compatible with modern browsers.

Industries that benefit most

In principle, every organization whose work largely happens in the browser and that must protect sensitive data benefits. RBI is particularly relevant for, among others:

  • Finance and insurance: protecting confidential customer and financial data from phishing and malware.
  • Healthcare: securing large volumes of sensitive patient data against data leaks and ransomware.
  • Government and the public sector: protecting critical data and infrastructure from web-based attacks.
  • Legal and consulting services: preserving the confidentiality of client and customer data.
  • Industry and manufacturing: protecting processes and control systems during web-based access.
  • Education and research: a safe learning environment and protection of intellectual property.

Benefits and limitations

Browser isolation delivers clear security gains, but it also comes with trade-offs you should know about.

The benefits

  • Higher security: malicious code runs remotely and has no direct access to the endpoint.
  • Malware and phishing protection: drive-by downloads come to nothing; entered credentials remain protected.
  • Zero-day risk contained: an attack would first have to overcome the isolated environment, not the local system.
  • Less data exfiltration: browsing activity takes place in the remote environment.
  • Legacy support: even older web applications remain usable.

The limitations

  • Latency and performance: since content is processed remotely and transmitted back, noticeable delays can occur, especially with interactive or media-rich pages.
  • Compatibility and user experience: not every website works smoothly in the isolated environment; individual functions or plugins may be limited.
  • Cost and resources: building and running a resilient RBI infrastructure requires servers, network, and computing power, to varying degrees depending on the approach.

Which rendering method is used significantly shapes these trade-offs. Modern methods such as Network Vector Rendering considerably reduce latency and compatibility problems.

What matters when choosing a solution

Anyone introducing RBI should clarify two questions above all:

  • Isolation technique: iframe-based solutions are cheaper but tend to be less secure; VM-based isolation is more secure but more complex.
  • Degree of isolation: some solutions separate the endpoint completely from the remote session, others allow deliberately limited, partial interaction.

The right choice depends on your protection needs, the applications in use, and your expectations for the user experience. A requirements-driven evaluation pays off here.

Browser isolation as part of Zero Trust and SASE/SSE

Browser isolation is not a standalone product but a building block of a comprehensive Zero Trust architecture. It delivers its full value in combination with Secure Web Gateway, Zero Trust Network Access (ZTNA), CASB, and email security, bundled in a SASE/SSE platform. Cloudflare, for example, offers browser isolation as part of Cloudflare One, which brings network and Zero Trust security services together in one global network.

How these building blocks interact is explained in detail in our article What is SASE/SSE? .

Browser isolation with KAEMI

The approach only becomes effective with the right implementation and ongoing management. As a managed security service provider and Cloudflare partner, we plan, integrate, and manage browser isolation as part of a SASE/SSE architecture , from a single source.

We assess which building blocks fit your requirements, integrate them cleanly into your existing environment, and then take on monitoring, hardening, and further development, with clear response times and a dedicated point of contact. More on our Professional Services page and in the overview of Cloudflare products for Zero Trust and SASE/SSE .

This article draws on the learning articles from Cloudflare ("What is browser isolation?") and Nomios ("What is Remote Browser Isolation (RBI)").

Want to secure access consistently with Zero Trust?

KAEMI designs, implements and manages SASE/SSE with Cloudflare One: ZTNA instead of VPN, verified access from anywhere — as a managed service.