Data masking

What it means

Data masking replaces part or all of a sensitive value with a safe stand-in, so most people and systems never see the real thing. A card number shows as ending in 4242, an email as a***@example.com, a phone number with the middle digits hidden. The real value stays stored for the few who need it.

The idea that makes it click: masking is about display and copies, not about protecting the store itself. It limits who sees the full value on a screen, in a log or in a test database. It is a different job from encryption, which protects stored or moving data until someone with a key reads it.

Why it matters

Most exposure of sensitive data is accidental and ordinary. A support agent sees a full card number they do not need. A log file records the whole request. A developer copies production data into staging. Masking removes the full value from places it was never needed.

It is also expected by rules. PCI DSS limits how much of a card number may be shown and requires the full number to be unreadable wherever it is stored. Masked data in non-production systems reduces the damage if a test environment leaks, which counts under data minimisation.

How it shows up

There are two main forms. Display masking hides digits in screens, exports and API responses. Masking for test data replaces real values in a copy of production with realistic fake ones. Related ideas are tokenisation, which swaps a value for a token, and encryption at rest.

Common mistakes: masking only in the web page while the API response still carries the full value, which anyone can read from the network tab. Logs that record raw request bodies. Masks too weak to hide the value, such as hiding one digit. Check the response itself, not only what the screen shows, and look at excessive data exposure.