Do both, in that order. Redact at the source so a secret never leaves the process, then add a pipeline filter as a safety net for what slips through. Source redaction is more reliable. Pipeline redaction is easier to roll out across many services.
Definitions
Source redaction means the application removes, masks or never records a sensitive value when it builds the log line. Pipeline redaction means a collector or shipper rewrites events after they leave the process but before they reach storage.
The OWASP Logging Cheat Sheet lists data that should usually be removed, masked, sanitized, hashed or encrypted rather than logged directly: source code, session identifiers, access tokens, passwords, database connection strings, encryption keys, payment data and some personal data. It also says that in some systems, sanitization can be done after log collection and before log display, which is the pipeline option.
Comparison
| Factor | At the source | In the pipeline |
|---|---|---|
| Secret leaves the process | No | Yes, briefly |
| Local log files protected | Yes | No, files hold the raw value |
| Works for every language | No, needs code changes | Yes |
| Speed to roll out | Slow | Fast |
| Pattern guessing needed | Rarely, you know the field | Yes, regex on text |
| Risk of missing a case | Low for known fields | Higher for free text |
The row that decides most arguments is local files. A pipeline filter does nothing about the log file on the host or the container stdout buffer, which administrators and crash tooling can read.
Steps
- Start with an allow list of fields for structured events, so unknown fields are not logged. See log field allow list versus deny list.
- Wrap logging of request objects. Log selected fields, never the whole object.
- Replace secrets with a fixed marker at the source. Use a stable hashed value only when you need to correlate events and the original is not guessable.
- Add a pipeline processor for known patterns such as authorization headers and card numbers. See OpenTelemetry collector redaction and filter processors.
- Alert when the pipeline redacts something. A hit means a source bug that should be fixed.
- Test both layers with fake values. See test log redaction with canary values.
Where each layer fails
Source redaction fails when a developer logs a new field or an exception message that embeds a value. Pipeline redaction fails on formats the patterns do not expect, such as a token split across lines or encoded. Neither layer is complete alone, which is why the second one is a backstop and not a plan.
Treat a pipeline redaction hit as an incident of low severity: rotate if the value was live, and fix the source.
Quick check
Is hashing a password in a log enough?
The OWASP guidance says passwords should not be logged at all. Do not record them in any form.
If I redact in the pipeline, are my log files safe?
No. The raw value still exists in local files and buffers before the pipeline sees it.
Safeguard's policies and gates can block risky dependency changes before they ship. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
