← Back

0plaintext

The passwords we were never supposed to see

Ended plaintext password capture in session recordings

ownership · security

Context

In 2023 I took over Zipy's browser SDK after the engineer who built it left. It was recording user sessions on sixty to seventy customers' production sites.

The problem

Reviewing the capture paths, I found passwords and other sensitive form inputs being captured unmasked in session recordings and breadcrumbs. Real credential and PII exposure.

This wasn't code I wrote. But once you own something, its gaps are yours, and I hadn't audited that path soon enough. That makes this a failure story before it's a fix.

What I did

I implemented a configurable textMasking parameter so sensitive fields are masked before capture, not redacted after.

Mask, don't redact

If a sensitive value reaches the pipeline, it exists in memory, in transit and in storage — three exposure surfaces and an obligation to delete it. Masking in the SDK means the value never becomes data at all. Redaction is remediation; masking is prevention.

What it cost

I made it configurable, which was pragmatic for existing customers. But secure-by-default is the right answer — masked unless explicitly opted out. A flag customers have to discover is one most of them never will.

Outcome

No more plaintext passwords in session recordings going forward, and data-capture review became standing practice rather than a one-time audit.

What I learned

"Secure by default" is something you actively verify, not something you assume because nobody has flagged it. And an ownership handover needs an explicit security pass, not just a code walkthrough.