Known limitations
Below, you will find information regarding the current limitations for Browser Isolation.
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. To turn off WebGL in the browser, refer to WebGL Rendering Error.
- Netflix and Spotify Web Player are unavailable.
- Modern Chromium, Google Chrome, Mozilla Firefox, Safari, Edge (Chromium) and Opera are supported.
- Internet Explorer 11 and below is unsupported.
Browser Isolation is not supported in virtualized environments (VMs).
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.
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.
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.
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.
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).
The following workarounds enable isolating SAML applications with Browser Isolation.
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.
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).
Configure a self-hosted application in Cloudflare Access and enable browser isolation in the application settings.
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 |
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 | |