Zscaler - Cloud Browser Isolation

Cloud Browser Isolation in ZIA

Cloud Browser Isolation (CBI) renders web content in a remote, containerized browser running in the Zscaler cloud rather than on the end user's device. Instead of downloading HTML, CSS, JavaScript, and other active content to the endpoint, the isolated session streams back only a safe visual representation of the page. The user can still click, scroll, type, and interact normally, but the underlying code from the destination site never actually reaches the endpoint or the corporate network.

Organizations use CBI to reduce the risk of web-based threats such as malware, ransomware, and phishing, particularly for site categories or user groups that carry elevated risk but still need internet access. Because CBI integrates natively with Zscaler Internet Access (ZIA), admins can apply it selectively through existing policy constructs rather than isolating all web traffic. It also lets users safely view file types such as Office documents in the browser without downloading them to the local machine.

Isolation Profiles

Any ZIA policy rule that uses the Isolate action must reference an isolation profile, which defines how the isolated session behaves: how its traffic is routed, what the user can do inside the isolated browser, where the isolation containers run, and what the experience looks like. Every profile starts with a name and description used to identify it when building policy.

The profile's company settings control how the isolation container reaches the internet. A proxy auto-configuration (PAC) file, applied inside the container itself, forwards the isolated session's traffic through the ZIA cloud rather than directly to destination servers. Admins can also choose whether to override that PAC file and force traffic back to the nearest ZIA Public Service Edge; because Public Service Edges use auto-geoproximity based on the user's location rather than the container's, this override is typically left disabled. Each profile must also reference at least one root certificate for SSL inspection — the Zscaler root certificate is included by default, and organizations using custom certificates for SSL inspection can add up to ten more.

The security settings determine what a user can do inside an isolated session: whether copy/paste between the local machine and the isolated browser is allowed, whether printing and keyboard/text input are permitted, whether Office file types can be viewed in isolation, and whether certain content renders locally instead of remotely. File transfer is controlled the same way, and when it's allowed, the profile can further specify whether transferred files arrive as flattened PDFs, sandbox-scanned files, or the original file.

Every profile also specifies at least two regions from which isolation containers can run; a container is provisioned from whichever selected region offers the lowest latency to the user. Finally, the isolation experience settings define what the user sees: a banner must be selected to indicate when a page is isolated, and admins choose between a native browser experience (behaving like a typical local session) and a browser-in-browser experience (presenting the full look and feel of an isolated session). Cookie persistence is also set here — when enabled, cookies from isolated sites are kept in encrypted storage across sessions; when disabled, they are destroyed with the container at logout or timeout.

Isolation Policy

Isolation is applied through the same URL Filtering policy admins already use to control web access in ZIA, rather than through a separate rule type. Admins set Isolate as the rule's action and pair it with one of the isolation profiles described above. When traffic matches the rule's criteria, ZIA redirects it into an isolated browser container governed by that profile instead of simply allowing or blocking it.

As with any URL Filtering rule, admins define the rule order, name, and match criteria — including request methods, protocols, and user agent. The Isolate action carries a few additional technical requirements before it can be enabled: the protocol must be limited to HTTP, HTTPS, or both; the allowed HTTP methods are restricted to CONNECT, GET, TRACE, and HEAD, since these cover standard page retrieval rather than data upload or modification; and the user agent criteria must include at least one recognized browser, since isolation is built around rendering pages for a real browser session. If a rule's criteria fall outside these boundaries, Isolate is not available and a different action must be used.

Together, isolation profiles and isolation policy let admins contain web-based risk without blocking legitimate use of the internet: a well-scoped URL Filtering rule identifies which traffic to treat as higher risk, and the referenced isolation profile determines exactly how that traffic behaves once it is routed into the isolated browser.