How to Mask Sensitive Data During Co-Browsing

Co-browsing lets an agent see and guide a customer's screen in real time, but that same power creates an obvious risk: card numbers, passwords, or health details can be exposed mid-session. Learning how to mask sensitive data during co-browsing isn't an optional extra, it's the requirement that separates a useful feature from a compliance liability. This guide covers which fields to hide, how masking is configured, and the practices that prevent accidental leaks.

What masking means in co-browsing

Masking means the contents of certain page elements never leave the customer's browser to reach the agent's. The agent sees the page structure (the form, the buttons, the layout) but the actual field value shows up as asterisks, a gray block, or simply empty. The customer types normally; the agent assists without ever reading the value.

This is different from "covering" something with a visual overlay. Good masking happens at the source: the data is filtered before it's transmitted, so it never travels the network and never lands in session logs or recordings.

Fields you should always mask

Not everything is equally sensitive. As a baseline, hide by default:

• Payment data: card number, expiration date, and CVV. The CVV should never be visible, not even partially.
• Credentials: passwords, PINs, one-time tokens, and security answers.
• Government identifiers: national ID, social security, passport numbers.
• Health data: diagnoses, medications, lab results.
• Financial data: balances, full account numbers, transactions.

A useful rule: if a field isn't needed for the agent to help you, mask it. The agent doesn't need to see your password to guide you to the right screen.

How masking is configured

There are two approaches worth combining.

1. Selector-based masking

You define rules based on the HTML: by CSS class, by name attribute, by input type, or by a dedicated attribute like data-cobrowse-mask. It's precise and predictable. For example, you flag every input[type=password] and every element with the .sensitive class so it's always hidden.

2. Pattern-based masking

As a safety net, you apply rules that detect formats: sequences that look like cards (16 digits), emails, or long numbers. It's less exact but catches fields you forgot to tag. Don't rely on it alone, because false negatives are expensive.

The ideal setup masks the critical fields by default and audits every new screen before enabling it for co-browsing.

Best practices that prevent leaks

• Mask from the first rollout, not "later." Privacy debt is paid back in incidents.
• Test with realistic dummy data: fill the form and confirm from the agent side that nothing is readable.
• Log and audit: record who started the session, when, and on which pages, but never the masked content.
• Give the customer control: let them pause sharing or end the session with an always-visible one-click button.
• Limit scope: co-browsing restricted to your own domain keeps the agent from seeing other tabs or the customer's email.

Balancing usefulness and privacy

The common mistake is assuming more visibility is always better. In reality, well-masked co-browsing usually resolves just as fast: the agent sees where the customer is stuck without needing the secret value. The trust that comes from knowing "the CVV isn't visible" reduces drop-off at critical steps like checkout.

In omnichannel platforms like Omnifox, co-browsing is designed to start from an existing conversation with configurable masking of sensitive fields, so the agent assists within your own domain without exposing payment data or credentials. The feature integrates with the inbox, CRM, and customer history without opening a privacy gap.

Quick checklist

1. Identify every sensitive field per screen.
2. Mask the critical ones by selector and add patterns as backup.
3. Verify from the agent side that the value isn't transmitted.
4. Restrict co-browsing to your domain.
5. Give the customer a visible button to pause or end.
6. Audit access without logging content.

Masking and session recording

Many companies record support sessions for training or auditing. Here masking is doubly important: if the data is filtered at the source, it won't appear in the recording either. Confirm your tool masks BEFORE it captures, not after. A recording with a visible CVV is a leak that stays on file.

Some recommendations:

• Record only if you have a clear legal basis and inform the customer.
• Apply limited retention: delete recordings when you no longer need them.
• Restrict who can replay them.

Common myths

"If the agent promises not to look, that's enough." No. Protection must be technical, not a promise. "Masking breaks the experience." On the contrary: the customer types normally and the agent sees the context. "Only payment needs protection." False: credentials, health, and government IDs are just as critical. The rule is simple: mask by default and expose only what's needed.

Conclusion

Masking sensitive data during co-browsing is what turns a visual support feature into a secure, trustworthy tool. With selector rules, backup patterns, and customer control, you deliver real-time assistance without compromising privacy. If you want to roll out co-browsing with masking from day one, inside an omnichannel inbox, try Omnifox and configure protection before your first session.