Designing Secure Co-Browse Experiences with Automated PII DOM Element Masking

How-To-Articles
1

Designing Secure Co-Browse Experiences with Automated PII DOM Element Masking

What This Guide Covers

  • Architecting a secure Co-browse deployment for high-compliance environments (Healthcare, Finance).
  • Implementing granular DOM element masking to prevent agents from viewing PII (Personally Identifiable Information) during a shared session.
  • Configuring security policies and whitelists to ensure the integrity of the Co-browse bridge.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 1/2/3.
  • Permissions:
    • Cobrowse > Session > View
    • Admin > Cobrowse > Edit
  • Technical Knowledge: Basic understanding of CSS selectors and the Genesys Cloud Co-browse SDK (cobrowse.js).

The Implementation Deep-Dive

1. The Co-browse Security Architecture: DOM Mirroring

Genesys Cloud Co-browse does not send a video stream of the user’s screen. Instead, it performs DOM Mirroring-sending the HTML structure and CSS state of the page to the agent’s browser. This architecture is inherently more secure than screen sharing because it allows you to intercept and mask specific elements before they leave the customer’s device.

The Implementation:

  1. Include the Co-browse script on your website.
  2. Define the Masking Strategy using CSS classes.
  3. The Trap: Relying on “Native Masking” alone. While Genesys Cloud automatically masks password fields and certain credit card inputs, it cannot know if a custom <div> contains a Social Security Number or a private medical diagnosis. You must explicitly tag these elements.

2. Implementing Granular PII Masking via CSS Selectors

The most efficient way to secure a session is by using the data-cobrowse-mask attribute or specific CSS classes in your Co-browse configuration.

The Implementation:

  1. In your application code, add the attribute to sensitive fields:
    <input type="text" name="ssn" data-cobrowse-mask="true">
  2. In the Genesys Cloud Admin UI (Admin > Quality > Cobrowse), you can also define Global Masking Rules using CSS selectors:
    • .private-data
    • #account-balance
    • input[name="cvv"]
  3. The Trap: Masking the “Submit” button or critical navigation elements. If you mask the buttons required to complete a transaction, the agent cannot guide the customer effectively. Always test your masking rules in a staging environment to ensure the “Supportability” of the page remains intact.

3. Architecting “Strict Mode” and Allowed Domains

To prevent your Co-browse script from being hijacked or used on unauthorized sites, you must implement strict origin controls.

The Configuration:

  1. Navigate to Admin > Quality > Cobrowse > Settings.
  2. Add your fully qualified domain names (e.g., https://secure.payments.com) to the Allowed Domains list.
  3. Enable Strict Mode for CSS and Iframe loading.
  4. Architectural Reasoning: Strict Mode ensures that the agent’s view only loads assets (images, fonts, scripts) from your whitelisted domains. If an attacker attempts to inject a malicious stylesheet into the session, Genesys Cloud will block the rendering on the agent’s side.

4. Handling the “Agent Control” vs. “View Only” Conflict

In regulated industries, agents should often be allowed to see the page to guide the customer but should be blocked from clicking buttons or typing on the customer’s behalf (Control Mode).

The Implementation:

  1. In the Co-browse deployment settings, disable Agent Control by default.
  2. If control is required for specific workflows, implement a Consent UI using the Co-browse SDK’s on('session.requestControl') event.
  3. The Trap: Enabling Agent Control without “Input Masking” on the customer’s side. If an agent has control and clicks into a masked field, they might be able to trigger a “Value Reveal” depending on how your frontend handles focus events. Always ensure that data-cobrowse-mask elements are also set to pointer-events: none for the agent’s virtual cursor.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Lazy Load” Masking Failure

Failure Condition: A customer clicks a “Show Details” button that loads a modal via AJAX. For a split second, the PII is visible to the agent before it is masked.
Root Cause: The DOM mutation occurs faster than the Co-browse observer can apply the masking rule.
Solution: Apply the data-cobrowse-mask attribute to the parent container of the modal, or use the Co-browse SDK’s maskElement(element) function immediately within your AJAX success callback.

Edge Case 2: Iframe Blindness

Failure Condition: The customer navigates to a section of the site hosted in a 3rd-party iframe (e.g., a payment gateway), and the agent sees a grey box.
Root Cause: Co-browse cannot look into iframes unless the Co-browse script is also present inside that iframe and the iframe is on an allowed domain.
Solution: Coordinate with your 3rd-party vendors to include the Co-browse shim in their hosted pages, or use a “Post-Message Bridge” to pass the necessary context to the parent frame.

Edge Case 3: Performance Degradation with Heavy Masking

Failure Condition: On pages with thousands of DOM elements (like a massive data table), the Co-browse session becomes laggy or disconnects.
Root Cause: The Co-browse engine is struggling to calculate the visibility state and masking rules for too many elements simultaneously.
Solution: Use Container Masking instead of individual element masking. Masking one parent div is significantly more performant than masking 500 child span elements.

Official References