Skip to content

Known limitations

Below, you will find information regarding the current limitations for Browser Isolation.

Website compatibility

Our Network Vector Rendering (NVR) technology allows us to deliver a secure remote computing experience without the bandwidth limitations of video streams. While we expect most websites to work perfectly, some browser features and web technologies are unsupported and will be implemented in the future:

  • Webcam and microphone support is unavailable.
  • Websites that use WebGL may not function.
  • Netflix and Spotify Web Player are unavailable.

Browser compatibility

  • Modern Chromium, Google Chrome, Mozilla Firefox, Safari, Edge (Chromium) and Opera are supported.
  • Internet Explorer 11 and below is unsupported.

Virtual machines

Browser Isolation is not supported in virtualized environments (VMs).

Gateway selectors

Certain selectors for Gateway HTTP policies bypass Browser Isolation, including:

You cannot use these selectors to isolate traffic, and isolation matches for these selectors will not appear in your Gateway logs.

File download size

When a user downloads a file within the remote browser, the file is held in memory and destroyed at the end of the remote browser session. Therefore, the total size of files downloaded per session is shared with the amount of memory available to the remote browser. We recommend a maximum individual file size of 512MB.

Multifactor authentication

Clientless Web Isolation does not support Yubikey or WebAuthN. These authentication technologies require the isolated website to use the same domain name as the non-isolated website. Therefore, they will not work with prefixed Clientless Web Isolation URLs but will work normally for in-line deployments such as isolated Access applications.

SAML applications

When Browser Isolation is deployed in-line (for example, via WARP, Gateway proxy endpoint or Magic WAN) it is possible to configure a subset of traffic to be isolated. Browser Isolation segregates local and remote browsing contexts. Due to this, cross-domain interactions (such as single sign-on) may not function as expected.

POST request returns 405 error

This error typically occurs due to SAML HTTP-POST bindings. These are not yet supported between non-isolated Identity Providers (IdP) and isolated Service Providers (SP).

Workarounds

The following workarounds enable isolating SAML applications with Browser Isolation.

Use SAML HTTP-Redirect bindings

Configure your SAML implementation to use HTTP Redirect Bindings. This avoids the HTTP 405 error by using URL parameters to route SAMLResponse data into the isolated SP.

Clientless Web Isolation

Direct your users to use access the application via Clientless Web Isolation. Clientless Web Isolation implicitly isolates all traffic (both IdP and SP) and supports HTTP-POST SAML bindings.

For user convenience, create a bookmark in Cloudflare Access for your application (for example, https://<authdomain>.cloudflareaccess.com/browser/https://example.com).

Add the application to Access

Configure a self-hosted application in Cloudflare Access and enable browser isolation in the application settings.

Isolate both Identity Provider and Service Provider

The HTTP 405 error does not occur when both the IdP and SP are isolated.

OrderSelectorOperatorValueAction
1ApplicationInYour Identity Provider, Your ApplicationIsolate

In-line SSO between Okta and Salesforce

Some applications that use HTTP-POST bindings (for example, Salesforce) complete SSO with an internal HTTP Redirect. Applying a Do Not Isolate policy to the SAML HTTP-POST endpoint enables the SAML flow to complete, and authenticate the user into the application in the remote browser.

Order

Selector

Operator

Value

Action

1

Hostname

In

Your Salesforce Application Domain

And

HTTP Method

In

POST

Do Not Isolate

2

Hostname

In

Your Salesforce application domain

Isolate