🌐 Trang này chưa được dịch sang tiếng Việt — đang hiển thị nội dung tiếng Anh.
Module 5c — Remote Browser Isolation (RBI)
Goal: Run risky or sensitive web browsing inside a remote browser on Cloudflare's network instead of on the user's device — so malware never reaches the endpoint, and you can disable copy/paste, downloads, printing, and keyboard input to stop data loss.
| 👤 Who does this | Security team |
| ⏱️ Time | ~30 minutes |
| 🎯 You'll finish with | An Isolate policy that renders chosen sites in a remote browser, plus (optionally) clientless isolation for unmanaged devices |
| ✋ Before you begin | Module 5 done (devices in Gateway with WARP, TLS decryption on). RBI requires Browser Isolation seats on your plan. |
🧭 How it works: When a page is isolated, a headless browser runs on Cloudflare's network and acts as a "clone" of the user's browser. Only safe draw commands are streamed to the device — no website code ever executes locally. Because every isolated request still passes through Gateway, all your DNS/HTTP/DLP policies keep applying.
Why use RBI
| Use case | What isolation gives you |
|---|---|
| Risky / uncategorized / newly-seen sites | Users can still open them, but code runs remotely — zero-day browser exploits can't touch the device |
| Unmanaged / BYOD / contractor devices | Give secure, clientless browser access with no software install |
| Stop data loss | Disable copy/paste, downloads, uploads, printing per policy |
| Protect against AI data leaks | Allow ChatGPT etc. but disable paste/upload so proprietary data can't go in |
| Phishing protection | Disable keyboard input on suspicious sites so credentials can't be typed |
The two ways to isolate
| Mode | How users reach it | Best for |
|---|---|---|
| In-line | Normal URLs, inspected by Gateway (needs the Cloudflare One Client, a PAC file / proxy endpoint, or Cloudflare WAN) | Managed devices — seamless, users don't notice |
| Prefixed URL (clientless) | Users visit https://<team-name>.cloudflareaccess.com/browser/<URL> |
Unmanaged / BYOD / contractors — no install needed |
We'll set up in-line isolation first (Part A–C), then optionally enable clientless (Part D).
Part A — Find the Browser Isolation overview
- 👉 In the dashboard (
https://one.dash.cloudflare.com), find Browser Isolation in the left navigation. - 📺 What you'll see: the Browser Isolation Overview page — a central place to set up isolation policies, test clientless isolation, and monitor usage and blocked actions.
✅ Checkpoint: You can see the Browser Isolation overview. (If it's missing or greyed out, your plan doesn't have RBI seats — contact your account team.)
Part B — Create an Isolate policy
Isolation is just an Action inside a Gateway HTTP policy (the same place you built rules in Module 5).
-
👉 Go to Traffic policies → Firewall policies → HTTP (or Gateway → Firewall Policies → HTTP).
-
👉 Click Add a policy.
-
⌨️ Policy name:
Isolate risky browsing. -
👉 Build the rule — for example, isolate uncategorized and newly-seen sites:
Selector Operator Value Content Categories in Newly Seen Domains,Unreachable/Uncategorized -
👉 Action: Isolate.
-
👉 Click Create policy.
📺 What happens: matching sites now open in a remote browser. Users browse normally — most won't even notice.
💡 Other useful targets: isolate a Security Risks category, a specific risky Domain, or an Application (e.g. isolate all AI tools). You can also use the Do not Isolate action to carve out exceptions above a broad Isolate rule.
Part C — Add data-protection controls (policy settings)
This is where RBI becomes a data-loss tool. When editing an Isolate policy, open its policy settings and toggle any of these:
| Setting | What it stops | Great for |
|---|---|---|
| Disable copy / paste | Copying between the remote page and the local device | Stop pasting proprietary code into third-party chatbots |
| Disable file downloads | Downloading files from the isolated site | Prevent data exfiltration from risky sites |
| Disable file uploads | Uploading local files to the isolated site | Stop sensitive docs leaving via web uploads |
| Disable printing | Printing the remote page | Prevent contractors printing confidential info |
| Disable keyboard input | Typing into the remote page | Phishing sites — users can't enter credentials |
- 👉 Open your Isolate policy → policy settings.
- 👉 Enable the controls you need (e.g. Disable copy/paste + Disable file downloads for risky categories).
- 👉 Save.
💡 Tip (AI data protection): create an Isolate policy for AI apps (ChatGPT, Gemini, Claude…) with Disable copy/paste and Disable file uploads — people can still use AI, but can't feed it your sensitive data. This pairs well with Module 7.
Part D — Clientless isolation (for unmanaged devices, no install)
Give contractors or BYOD users a safe browser through a simple link — no Cloudflare One Client required.
D1 — Turn on clientless access
- 👉 Go to Settings → Browser Isolation (or the Browser Isolation overview).
- 👉 Enable Allow users to open a remote browser without the device client.
- ✅ Make sure Browser Isolation (RBI) seats are assigned to your account.
D2 — Share the prefixed URL
Users reach any site safely by prefixing it with your team domain:
https://<team-name>.cloudflareaccess.com/browser/https://example.com
For Acme: https://acme.cloudflareaccess.com/browser/https://example.com
📺 The site loads inside a remote browser tab. Your Access login can gate who's allowed to use it.
💡 Bonus — isolate a private app (ZTNA): you can also render a self-hosted Access application in a remote browser so unmanaged devices get access without exposing your app. Configure this via Access → Applications → (your app) → policies → Isolate — a great fallback for the "unmanaged device" scenario from Module 4.
Part E — Verify isolation is working
On a device covered by your policy:
- 👉 Visit a site that matches your Isolate rule (e.g. a newly-registered domain, or use the clientless prefix URL).
- 👉 Confirm it's isolated using either method:
- Click the padlock in the address bar → the certificate is issued by the Cloudflare Root CA.
- Right-click the page → the context menu shows the isolated-browser options.
- 👉 Test your controls: try to copy text or download a file — they should be blocked if you enabled those settings.
- 👉 Check the Browser Isolation overview (or Logs → Gateway → HTTP) for isolation activity and blocked actions.
✅ Checkpoint: Matching sites render in a remote browser, your data-protection toggles are enforced, and isolation activity shows in the dashboard. 🎉
✅ Module 5c complete!
You now have:
- ✅ An Isolate policy rendering risky sites in a remote browser
- ✅ Data-protection controls (copy/paste, download, upload, print, keyboard) applied
- ✅ (Optional) Clientless isolation for unmanaged/BYOD devices
- ✅ A verified isolation test and visibility in the overview
Quick troubleshooting
| Problem | Fix |
|---|---|
| No Browser Isolation in the menu / Isolate greyed out | Your plan lacks RBI seats — contact your account team |
| In-line isolation doesn't trigger | Device must be in Gateway with WARP with TLS decryption on (Module 5–6); confirm the policy selector matches |
| Clientless prefix URL fails | Enable Allow users to open a remote browser without the device client and assign RBI seats (Part D1) |
| A site breaks when isolated | Some sites don't render well remotely — add a Do not Isolate policy above the Isolate rule for that domain |
| Copy/paste still works | Re-check the Isolate policy's policy settings and save; test in a fresh isolated session |
👉 Next: Module 6 — DLP
Detect and stop sensitive data from leaving your organization.