Redact secrets from a config file ENVSHIELD

What it masks, and how it finds it

Two ways, because neither is enough alone.

• By the name on the left. Anything whose key contains KEY, TOKEN, SECRET, PASSWORD, PASSWD, AUTH, CREDENTIAL, PRIVATE, SALT or SIGNATURE. This is what catches a house-named variable nothing else would recognise.
• By the shape on the right. The prefixes real services use (sk_live_, AKIA, ghp_, xox, eyJ for a JWT), a PEM block between its BEGIN and END lines, a connection string with a password inside the URL, and long high-entropy strings that are not words. This is what catches a secret in a key called value.

It leaves the readable settings alone, which is the point: a config file with every value masked is no use in a bug report. Ports, hostnames, feature flags, log levels and timeouts stay as they are.

What it cannot see

• A secret that looks like an ordinary word. A password of correct-horse in a field called note has neither a telling name nor a telling shape.
• A secret in prose. "I set the admin password to hunter2 last Tuesday" in a log line is a sentence.
• Anything that is sensitive for a reason other than being a secret. Internal hostnames, private IP ranges, S3 bucket names, customer identifiers and the path layout of your servers are all reconnaissance, and none of them is a credential. Read what you are pasting.

Rotate anyway

The important thing, and the thing masking cannot do for you: if a real key has already been in a ticket, a gist, a chat or a screenshot, masking a later copy does not help. It is out. Rotate it. Secret scanners run continuously against public repositories and paste sites, and the interval between a key appearing and being used is frequently measured in minutes.

Use this before the first paste, not after. For a network capture or a curl command rather than a config file, INTERCEPT does the same job on that shape of text.