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.
| Order | Selector | Operator | Value | Action |
|---|---|---|---|---|
| 1 | Application | In | Your Identity Provider, Your Application | Isolate |
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 | |