Lab 8 — In-Browser Protection using Browser-Based DLP
Labs 6 and 7 demonstrated how Inline Web DLP and Endpoint DLP stop data exfiltration at the network and OS layers. But what about sensitive data that never leaves the browser at all — content typed into a GenAI prompt, credentials pasted into a cloud IDE, or a sensitive document viewed in a browser tab? These interactions happen entirely inside the browser, invisible to the proxy and outside the reach of endpoint file controls. Browser-Based DLP is purpose-built for exactly this gap.
Browser-Based DLP does not replace Inline Web DLP or Endpoint DLP. Each operates at a different control point and covers a different threat surface:
| Control | Where it operates | What it covers |
|---|---|---|
| Inline Web DLP (Lab 6) | Network proxy | Data leaving via HTTP/S uploads |
| Endpoint DLP (Lab 7) | OS / agent layer | File access, removable storage, clipboard to local apps |
| Browser-Based DLP (Lab 8) | Inside the browser | Content that stays within the browser — GenAI prompts, cloud IDEs, browser-rendered documents |
Together, the three layers form a complete data protection stack with no gaps.
All tasks in this lab must be performed from the lab VM using Google Chrome. The Zscaler Browser DLP Chrome extension must be active. Complete the prerequisite login steps below before starting Task 1.
Prerequisite — Log In to the Chrome Extension
Before any Browser-Based DLP controls will fire, Kevin must authenticate the Chrome extension using the lab credentials provided.
Prereq Step 1 — Open the Chrome Extension
Click the Zscaler extension icon in the Chrome toolbar to open the extension panel.
Prereq Step 2 — Enter the Tenant Identifier
Click Log in, enter dlpdemo as the tenant identifier, and click Continue.
Prereq Step 3 — Enter the Lab User ID
Enter the user ID provided for this lab session.
Prereq Step 4 — Select Okta SSO
Click Okta SDC SSO to proceed to identity provider authentication.
Prereq Step 5 — Complete IDP Authentication
Enter the user ID and password when prompted by the identity provider to complete the login.
Once login is successful you will see the "All set!" confirmation screen. This means the extension setup is complete. Do not click "Sign in as Admin" — it is not required for this lab. Close this tab and return to the lab guide.
Allow 2–3 minutes for all students to complete the extension login before starting Task 1. The extension must show an authenticated/active state before Browser-Based DLP controls will fire. If a student sees no block or mask in Task 1, the most likely cause is that the extension is not authenticated.
Credentials are pre-provisioned per seat — each student uses their own lab user ID. Do not share credentials between seats.
Task 1 — Mask Sensitive Values Before GenAI Submission
Demonstrate how Browser-Based DLP intercepts sensitive data typed or pasted into a GenAI prompt and masks it before submission — protecting data that never touches the network layer.
This is the scenario that resonates most with security leaders right now. GenAI prompts are a blind spot for proxy-based DLP — the content is typed or pasted inside the browser, and by the time it appears in an HTTP request it may already be processed client-side. Browser-Based DLP operates at the input layer, before submission.
Key message: "The proxy sees the request. The browser extension sees the keystrokes."
Steps
Kevin opens ChatGPT in Chrome and pastes the following customer record from the payroll document used in Labs 6 and 7:
📋 Content to paste into the ChatGPT prompt:
Customer name: Daniel Reeves
Email: daniel.reeves@acme-corp.com
Phone: +1 415-238-7712
SSN: 531-72-8943
Issue: Customer reported duplicate billing for invoice INV-4482 and
wants confirmation once the refund is processed.
As soon as Kevin pastes the content, the Browser-Based DLP extension detects the sensitive values — SSN, email, phone number — and masks them inline before the prompt is submitted. Kevin is notified that sensitive content has been redacted.
GenAI platforms process input client-side before sending it to the model. Proxy-based DLP sees the outbound HTTP request — but the sensitive data may already be embedded in a JSON payload or encrypted in transit. Browser-Based DLP intercepts at the input field level, before the content ever becomes part of a network request.
This control also applies to any browser-based form, chat interface, or text input — not just ChatGPT.
Task 2 — Block Paste of Credentials into a Cloud IDE
Demonstrate how Browser-Based DLP blocks a developer from accidentally pasting sensitive credentials into a browser-based code editor.
This use case speaks directly to developer security teams. Hardcoded credentials in source code are one of the most common causes of cloud data breaches. The scenario here is realistic: a developer copies an AWS access key or API secret from a config file and pastes it into a browser-based IDE like CodePen, Replit, or GitHub Codespaces.
Endpoint DLP does not inspect browser traffic — it operates at the file and OS layer. This is why Browser-Based DLP is the right control for this scenario, not a proxy or endpoint policy.
Steps
Kevin opens a browser-based IDE (CodePen or similar) in Chrome. He copies the following AWS credentials from a local config file and attempts to paste them into the code editor:
📋 Content to copy and paste into the browser IDE:
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
[dev-profile]
aws_access_key_id = AKIAEXAMPLE123456789
aws_secret_access_key = EXAMPLEsecretKEY987654321
aws_session_token = FwoGZXIvYXdzE... (only for temporary sessions)
The Browser-Based DLP extension detects the credential pattern — AWS access key IDs (AKIA...) and secret access keys — and blocks the paste action, preventing the sensitive values from entering the code editor.
A browser-based IDE never triggers a file transfer event — there is nothing for Endpoint DLP to intercept. The content goes directly from clipboard to browser DOM. Browser-Based DLP is the only layer that operates at this point in the data flow.
This control protects against both accidental exposure (developer didn't realize the clipboard contained live credentials) and intentional exfiltration via cloud coding environments.
Task 3 — Dynamic Watermark with Viewer Identity
Demonstrate how Browser-Based DLP dynamically watermarks sensitive documents viewed in the browser with the viewer's identity — creating a visual deterrent and forensic trail without altering the source file.
Watermarking is a deterrent and a forensic control, not a prevention control. The message to the audience: "We cannot always prevent someone from taking a photo of their screen — but we can make sure that if they do, the watermark identifies exactly who was viewing that document at that moment."
This is particularly relevant for board decks, M&A documents, and HR records that are shared for review but must never be redistributed. The watermark follows the content in the browser regardless of whether the document is downloaded or screen-captured.
Steps
Kevin opens the following sensitive Dataparity document in Chrome — this document has been tagged for dynamic watermarking by the Browser-Based DLP policy:
📋 Open this link in Chrome on the lab VM:
https://docs.google.com/document/d/1hY6dxddc24anjf1U8GsnVtQwYvvPxasM59_NR35toQA/edit
As soon as the document renders in the browser, the extension overlays a dynamic watermark containing Kevin's identity — user name, email, and timestamp — across the document view.
The watermark is applied at the rendering layer — it exists in the browser DOM but not in the source file. This means the original document is never modified, and the watermark cannot be removed by downloading the file. It is a pure browser-side control.
Combined with DLP logging, this creates a complete chain: who viewed it, when, and on which device — without requiring any changes to document storage or access controls.
- Task 1 masked content before submission to ChatGPT. How would you handle a use case where a user legitimately needs to ask an AI assistant about a customer record — for example, a support agent using an internal AI tool?
- Task 2 blocked credential paste in a browser IDE. What other browser-based input surfaces in your environment could be a credentials exfiltration risk?
- Task 3 showed a deterrent watermark. Can you think of a scenario where watermarking alone is insufficient and a Block action would be required instead?
- Browser-Based DLP requires a Chrome extension. How would you handle employees using Firefox, Edge, or Safari — and what does that mean for your coverage model?
The three DLP layers work together, not in competition. Inline Web DLP (Lab 6) stops data at the network boundary. Endpoint DLP (Lab 7) stops data at the OS and file layer. Browser-Based DLP (Lab 8) stops data at the point of human interaction inside the browser — the one place neither of the other two layers can reach.
A complete data protection architecture requires all three. Any single layer leaves gaps that a determined insider — or an accidental action — can exploit.
Strong transition to Lab 9: "Kevin has now triggered DLP violations across three different channels — web upload in Lab 6, and browser interactions in Lab 8. In Lab 9, Priya picks up all of these incidents in the ZWA SOC console and investigates them as a SOC analyst. The full picture comes together there."
If attendees ask about mobile or non-Chrome browsers: Browser-Based DLP currently requires the Chrome extension. For other browsers and mobile, Inline Web DLP and Endpoint DLP provide coverage. This is a fair limitation to acknowledge — and a roadmap conversation worth having with your account team.